internal error on user creation with account manager and notification "gaierror: [Errno -2] Name or service not known"

[anonymous]

Hello,

this happens when creating new user with 'user creation notification' enabled. The user is created, however. When "Get notified of new account creation" is disabled, everything works fine. Maybe it is a good point to tell, that notification emails about ticket changes are working well, too.

Hoe the choosen hack is correct.

2013-05-16 14:25:55,751 Trac[git_fs] DEBUG: disabled CachedRepository for '/home/tic/sptc/PrimeFaces/.git'
2013-05-16 14:26:21,566 Trac[main] DEBUG: Dispatching <RequestWithSession "POST '/admin/accounts/users'">
2013-05-16 14:26:21,567 Trac[PyGIT] DEBUG: PyGIT.Storage instance 140363889453200 constructed
2013-05-16 14:26:21,576 Trac[api] INFO: Synchronized '(default)' repository in 0.01 seconds
2013-05-16 14:26:21,578 Trac[session] DEBUG: Retrieving session for ID u'admin'
2013-05-16 14:26:21,588 Trac[api] INFO: Created new user: newuser
2013-05-16 14:26:21,602 Trac[notification] INFO: Sending notification through SMTP at smtp.1und1.de:25 to [u'newuser@somewhere.com']
2013-05-16 14:26:41,626 Trac[main] ERROR: Internal Server Error:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/Trac-1.0-py2.7.egg/trac/web/main.py", line 497, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/local/lib/python2.7/dist-packages/Trac-1.0-py2.7.egg/trac/web/main.py", line 214, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/local/lib/python2.7/dist-packages/Trac-1.0-py2.7.egg/trac/admin/web_ui.py", line 125, in process_request
    path_info)
  File "build/bdist.linux-x86_64/egg/acct_mgr/admin.py", line 204, in render_admin_panel
    return self._do_users(req)
  File "build/bdist.linux-x86_64/egg/acct_mgr/admin.py", line 348, in _do_users
    acctmgr.validate_registration(req)
  File "build/bdist.linux-x86_64/egg/acct_mgr/api.py", line 367, in validate_registration
    self.set_password(username, req.args.get('password'))
  File "build/bdist.linux-x86_64/egg/acct_mgr/api.py", line 246, in set_password
    self._notify('created', user, password)
  File "build/bdist.linux-x86_64/egg/acct_mgr/api.py", line 393, in _notify
    getattr(listener, mod)(*args)
  File "build/bdist.linux-x86_64/egg/acct_mgr/notification.py", line 37, in user_created
    notifier.notify(username, 'New user registration')
  File "build/bdist.linux-x86_64/egg/acct_mgr/notification.py", line 87, in notify
    NotifyEmail.notify(self, username, subject)
  File "/usr/local/lib/python2.7/dist-packages/Trac-1.0-py2.7.egg/trac/notification.py", line 343, in notify
    Notify.notify(self, resid)
  File "/usr/local/lib/python2.7/dist-packages/Trac-1.0-py2.7.egg/trac/notification.py", line 231, in notify
    self.send(torcpts, ccrcpts)
  File "/usr/local/lib/python2.7/dist-packages/Trac-1.0-py2.7.egg/trac/notification.py", line 482, in send
    msg.as_string())
  File "/usr/local/lib/python2.7/dist-packages/Trac-1.0-py2.7.egg/trac/notification.py", line 124, in send_email
    self.email_sender.send(from_addr, recipients, message)
  File "/usr/local/lib/python2.7/dist-packages/Trac-1.0-py2.7.egg/trac/notification.py", line 153, in send
    server = smtplib.SMTP(self.smtp_server, self.smtp_port)
  File "/usr/lib/python2.7/smtplib.py", line 249, in __init__
    (code, msg) = self.connect(host, port)
  File "/usr/lib/python2.7/smtplib.py", line 309, in connect
    self.sock = self._get_socket(host, port, self.timeout)
  File "/usr/lib/python2.7/smtplib.py", line 284, in _get_socket
    return socket.create_connection((port, host), timeout)
  File "/usr/lib/python2.7/socket.py", line 553, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
gaierror: [Errno -2] Name or service not known
2013-05-16 14:26:41,667 Trac[chrome] DEBUG: Prepare chrome data for request
2013-05-16 14:26:41,671 Trac[PyGIT] DEBUG: PyGIT.Storage instance 140363897682576 constructed

[anonymous]

Similar thing happens on "Get notified of password reset" is triggered (tested) and probably also "Get notified of account deletion" (assumed).

[Ryan J Ollos]

Which version of AccountManagerPlugin are you running? Do you have notifications emails enabled from your Trac instance for ticket changes, and if so, do they work okay?

Could you post a sanitized version of your trac.ini [notification] section (​t:TracIni#notification-section)?

[Steffen Hoffmann]

Replying to anonymous:

Similar thing happens on "Get notified of password reset" is triggered (tested) and probably also "Get notified of account deletion" (assumed).

Because the error raises from within trac/notification, I'd be eager to know, if ticket change notifications work.

[Steffen Hoffmann]

While I suspect your local install/configuration to be the root cause, we might still us that case to make NotifyEmail.notify a bit more robust.

[Steffen Hoffmann]

​T:#8657 seems related, but that one is already more than 3 years old, hm.

[anonymous]

05/19/13 16:35:27 changed by hasienda While I suspect your local install/configuration to be the root cause, we might still us that case to make NotifyEmail.notify a bit more robust.

Sorry, I don't understand.

I have to correct the situation: Before installing account manager, system was able to send emails on ticket change. After installing account manager, not only account changes lead to described error, but also ticket changes produce it. And yes, my system configuration is probably root cause to it, because I can't send email via ssmtp any more from console. I'll check it out, there problems with 1und1 connect...

[anonymous]

sorry for delay, finally all email notications work again. There was an DNS resolv error in the system which seems to lead to the described error. With manual ssmtp email tests on console I got error message that smtp server couldn't be opened. This was neither caused by wrong port or something in ssmtp.conf nor wrong settings in trac.ini/account manager settings, but a general DNS config issue. So the only point left is catching this errors in log instead of GUI, so user won't be confused by an error, which doesn't affekt his work.

Thank You for development and support, great work!

[Ryan J Ollos]

It seems like Trac should be the one that is more robust about catching the error and raising an exception with an unambiguous message, but getting a patch into Trac seeems unlikely given my past experience (with patches to Trac in general, but especially the email notification component), and a patch to Trac wouldn't help us with all those versions of Trac prior to the patch anyway.

hasienda: Are you thinking to just catch this error in the AccountManagerPlugin code and raise an appropriate TracError? It seems like this is a case that we could be proactive about handling in the AnnouncerPlugin as well.

[Steffen Hoffmann]

Replying to anonymous:

This was neither caused by wrong port or something in ssmtp.conf nor wrong settings in trac.ini/account manager settings, but a general DNS config issue.

Nice, even outside of SMTP then, but still conforming to my initial guess: 'outside of this plugin', and good to get the confirmation now. Thanks for reporting back.

So the only point left is catching this errors in log instead of GUI, so user won't be confused by an error, which doesn't affekt his work.

Yes, this ticket has been left open to remind on addressing that issue.

Thank You for development and support, great work!

You're welcome.

[Steffen Hoffmann]

Replying to rjollos:

It seems like Trac should be the one that is more robust about catching the error and raising an exception with an unambiguous message,

This has been one of my immediate thoughts too.

but getting a patch into Trac seeems unlikely given my past experience (with patches to Trac in general, but especially the email notification component), and a patch to Trac wouldn't help us with all those versions of Trac prior to the patch anyway.

Right. But hard to blame Trac core devs for that. Its rather one more occasion reminding me to finalize the promising work started at TracAnnouncer alias AnnouncerPlugin. This is what I'm longing to, even if other priorities regularly distract me from getting there.

hasienda: Are you thinking to just catch this error in the AccountManagerPlugin code and raise an appropriate TracError? It seems like this is a case that we could be proactive about handling in the AnnouncerPlugin as well.

Handle it/any notification issue gracefully in AccountManager, if not done in the notification back-end, sure. But will implement a mild user notification and redirect the full trace to error logging rather then throw a TracError at the web-UI.

[anonymous]

@hasienda,rjollos As a final remark please let me say, I don't think that my issue is a trac error. There is a failure in a "sub" process, which has nothing to do with the core process of e.g. filing a new ticket(a) or admin notification for user pw changes (b). In fact both tasks succeeded.

What's obvious in case a): User is aware of related email notifications, he is even able to influence it. So an error message in GUI makes sense somehow, especially when follow up workflow is interupted by missing email notifications- which of course trac is unaware about. case b): User is not aware of related email notification and he shouldn't care about. Follow up "workflow" affected here is admin, missing a "pw changed" hint. So he has let's say a little loss of control.

Same reason, two different effects and maybe consequences. Each engine / plugin should have and stay with its responsibilities. I don't know about AnnouncerPlugin and it's purpose, but basically as administrator I should have possibility to test attached subsystems- best without (mis)-using a system workflow. But I'm getting verbose. Thanks again and good luck.

[Steffen Hoffmann]

In 13290:

AccountManagerPlugin: Catch notification issues for web-UI requests, refs #11090.

NotificationError handling provides appropriate information to both, admins
and users, preventing too fatal perception of errors from notification actions.
This works around insufficient error handling in notification back-ends,
what has been reported specifically for TracNotification.

Currently it is not explicite, if an AcctMgr method triggers a account change
notification, and notifications are not handled in a request context, what
complicates throwing anything but a fatal TracError.

I noticed, that SingleUserNotification already got protection against this
sort of errors, but I guess, sucking them unconditionally was not a good idea.
Remembering issues related to password reset without notification, that might
have been easier to debug with logging in place - done now.

[anonymous]

Execuse me, I stumbled uppon this again and noticed changeset [13290]. What happend: I disabled acct_mgr.notification.accountchangelistener, cause again got above error for some reason. Anyway, a user invoked "forgot my password" and claimed, he didn't receive password change email. I checked that and it turns out that acct_mgr.notification.accountchangelistener and email password change seem to be disabled together? If so, then why does UI not care about this?

And finally, what is described in [13290] sounds very close to this issue. So is it fixed now?

[Steffen Hoffmann]

Replying to anonymous:

Execuse me, I stumbled uppon this again and noticed changeset [13290].

Welcome.

What happend: I disabled acct_mgr.notification.accountchangelistener, cause again got above error for some reason. Anyway, a user invoked "forgot my password" and claimed, he didn't receive password change email.

How shall he? If you disabled that component, this would effectively disable all AcctMgr notifications.

I checked that and it turns out that acct_mgr.notification.accountchangelistener and email password change seem to be disabled together? If so, then why does UI not care about this?

I'll have to investigate for confirming this, but likely you have hit a weak spot here. About why, well, actually not the web-UI, rather the developer has to care about, and notification is not as mature as most other parts of this plugin yet.

Disabling a feature as long as at least one of its dependencies have not been met is desired, sure. However its harder to tell then to do for every single feature we have in this plugin today. Keeping track of all dependencies has been improved over time, but is certainly not perfect yet, so you'll likely find other combinations of enabled and disabled plugin components that won't work as expected. But it is OT here, and I strongly suggest to open another ticket for such issues for dealing with it separately.

And finally, what is described in [13290] sounds very close to this issue. So is it fixed now?

Fixed in trunk yes, but not in a stable release yet. Its planned to go into v0.5, but treat trunk as release candidate, if you need the fix now - just test it.

[Ryan J Ollos]

Replying to rjollos:

It seems like Trac should be the one that is more robust about catching the error and raising an exception with an unambiguous message,

What I've noticed lately is that Trac takes a similar approach to [13290], wrapping the notify call in try/except:

• ​in BatchModifyModule
• ​in TicketModule