savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] mail-sending error from git server updatin


From: Bob Proulx
Subject: Re: [Savannah-hackers-public] mail-sending error from git server updating emacs "concurrency" branch
Date: Thu, 5 Nov 2015 12:54:30 -0700
User-agent: Mutt/1.5.24 (2015-08-30)

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: address@hidden
> > 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 address@hidden:/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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]