#10029 closed enhancement (fixed)
Uninformative error message in commit_updater
| Reported by: | Owned by: | Ryan J Ollos | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.0.2 | 
| Component: | general | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Jun Omae | Branch: | |
| Release Notes: | 
           
Improve error messages that are raised when   | 
      ||
| API Changes: | 
           
Avoid   | 
      ||
| Internal Changes: | |||
Description
This is the message I see in log:
2011-02-16 16:44:09,653 Trac[commit_updater] ERROR: Failure sending notification on change to ticket #2: OSError: [Errno 2] No such file or directory
Would be perfect if this message includes the name of the file (or directory). Otherwise I can't understand what's going on.. This happens during changeset add operation triggered from post-commit SVN hook.
Attachments (0)
Change History (7)
comment:1 by , 15 years ago
| Keywords: | needinfo added | 
|---|
comment:2 by , 14 years ago
| Resolution: | → cantfix | 
|---|---|
| Status: | new → closed | 
No feedback in more than 3 months, closing.
comment:3 by , 12 years ago
| Priority: | normal → low | 
|---|---|
| Resolution: | cantfix | 
| Status: | closed → reopened | 
| Type: | defect → enhancement | 
I got a similar error message and was also confused.
Yes, I use SendmailEmailSender and the sendmail_path was sendmail. After changing it to /usr/sbin/sendmail the problem was solved.
An improved error message would be beneficial.
comment:4 by , 12 years ago
| Milestone: | → 1.0.2 | 
|---|---|
| Owner: | set to | 
| Status: | reopened → assigned | 
follow-up: 6 comment:5 by , 12 years ago
The patch in log:rjollos.git:t10029 attempts to improve the error message for a few different scenarios:
Incorrect [notification] smtp_server or [notification] smtp_port:
Incorrect [notification] sendmail_path:
tt tags need to be changed to code tags on merge to trunk (#11094). I'm not sure about using smtp.example.com in the test case. Maybe there is a better way?`
comment:6 by , 12 years ago
| Cc: | added | 
|---|
Replying to rjollos:
The patch in log:rjollos.git:t10029 attempts to improve the error message for a few different scenarios:
The socket.error isn't a child class in Python 2.5. Also, smtplib.SMTP.connect may raise a socket.error with empty strerror.
>>> try: ... smtplib.SMTP('localhost:123aaa', 0) ... except socket.error, e: ... print e ... print e.strerror ... nonnumeric port None
Oh, I noticed that strerror property of socket.error has a localized error string in Python 2.6+ on Windows.
>>> try: ... smtplib.SMTP('127.0.0.1', 65536) ... except socket.error, e: ... pass ... >>> e.strerror '\x97v\x8b\x81\x82\xb5\x82\xbd\x83A\x83h\x83\x8c\x83X\x82\xcc\x83R\x83\x93\x83e\x83L\x83X\x83g\x82\xaa\x96\xb3\x8c\xf8\x82\xc5\x82\xb7\x81B'
In Python 2.5 on Windows, the property is non-localized error string.
>>> try: ... smtplib.SMTP('127.0.0.1', 65536) ... except socket.error, e: ... print e ... (10049, "Can't assign requested address")
I suggest that we use to_unicode with the exception rather than strerror. Proposed changes are in log:jomae.git:t10029.1.
I'm not sure about using
smtp.example.comin the test case. Maybe there is a better way?`
How about using smtp_server = 127.0.0.1 and smtp_port = 65536, out of range, instead?
comment:7 by , 12 years ago
| API Changes: | modified (diff) | 
|---|---|
| Keywords: | needinfo removed | 
| Release Notes: | modified (diff) | 
| Resolution: | → fixed | 
| Status: | assigned → closed | 
Thanks! Committed to 1.0-stable in [12394:12396,12399,12401], merged to trunk in [12397,12400,12402] and tt tags replaced with code tags on the trunk in [12398].



  
This happens while sending the notification. Are your ticket change notifications working correctly (when you modify a ticket in the web interface)?
Are you using the
SendmailEmailSenderto send notifications? Then your[notification] sendmail_pathmay be wrong.Other than that, I don't see what could trigger such an error while sending notifications. Could you please post the few lines in the log before the one you posted above? Increasing the log level to DEBUG may provide more information about the cause.