Ken Raeburn wrote: > I got this error back from the git server while pushing an update to > the “concurrency” branch of emacs: >... > > remote: Sending notification emails to: emacs-di...@gnu.org > > remote: *** Error while generating commit email > > remote: *** - mail sending aborted. > > remote: Traceback (most recent call last):
Thanks for letting us know about the error. Although I installed that hook for the emacs team I am not a Python programmer and the only part of the backtrace that tells me anything is: > > remote: File "hooks/post-receive", line 62, in <module> > > remote: git_multimail.main(sys.argv[1:]) > > remote: File "/srv/git/emacs.git/hooks/git_multimail.py", line 2631, in > > main > > remote: run_as_post_receive_hook(environment, mailer) > > remote: File "/srv/git/emacs.git/hooks/git_multimail.py", line 2482, in > > run_as_post_receive_hook > > remote: push.send_emails(mailer, body_filter=environment.filter_body) > > remote: File "/srv/git/emacs.git/hooks/git_multimail.py", line 2462, in > > send_emails > > remote: rev.recipients, > > remote: File "/srv/git/emacs.git/hooks/git_multimail.py", line 1472, in > > send > > remote: p.terminate() > > remote: File "/usr/lib/python2.6/subprocess.py", line 1269, in terminate > > remote: self.send_signal(signal.SIGTERM) > > remote: File "/usr/lib/python2.6/subprocess.py", line 1264, in send_signal > > remote: os.kill(self.pid, sig) > > remote: OSError: [Errno 1] Operation not permitted "Operation not permitted" seems both clear and confusing at the same time. I mean, what operation? And why wasn't it permitted? I hate it when programmers are slack about error handling. Someone would need to look at the python source and debug it. We are using the Github project pretty much verbatim. At a guess if it were a very large message it would have exceeded the Exim configured message size limits. That might have resulted in an operation not permitted error in the python, maybe. But since you said the mail did go out that doesn't seem right either. > > To raeb...@git.sv.gnu.org:/srv/git/emacs.git > > 6a31219..39372e1 tmp -> concurrency > > This was Sunday morning, around 1:42AM EDT (not EST). The email did > go out, and it was a pretty large message, as this was merging over > two years’ worth of changes from master to the concurrency branch. > > Around the same time, from a different client machine, “git remote > update” got a “Connection reset by peer” error. A later attempt > worked fine. Thanks for reporting the result. However I think we can only shrug and with some regret say that we don't know. It obviously isn't a permission error or every commit would be failing. I can only imagine something resulted from the large size coupled with other things happening on the system. The vcs server VM is hosted on a system with a lot of other VMs and other I/O disk bandwidth. Just as a general statement we have always been seeing a lot of load spikes when the entire FSF environment is busy. Pretty much everything uses disk and bottlenecks there. It is possible something like that occurred and caused some timeout error which was misreported as a not-permitted error. Bob
