Issue 2551014
Created on 2018-11-26 11:24 by aparcar, last changed 2019-02-20 09:42 by schlatterbeck.
Messages | |||
---|---|---|---|
msg6299 | Author: [hidden] (aparcar) | Date: 2018-11-26 11:24 | |
The interface works fine except when sending emails by putting entries to the nosy list. The interface loads until it times out, no matter what timeout I set in the proxy. Receiving emails via mailgw works just fine. The error message looks like that: 127.0.0.1 - - [26/Nov/2018 11:18:18] "POST /support/issue4 HTTP/1.0" 500 - ---------------------------------------- Exception happened during processing of request from ('127.0.0.1', 46082) Traceback (most recent call last): File "/usr/lib/python2.7/SocketServer.py", line 571, in process_request self.finish_request(request, client_address) File "/usr/lib/python2.7/SocketServer.py", line 331, in finish_request self.RequestHandlerClass(request, client_address, self) File "/usr/lib/python2.7/SocketServer.py", line 654, in __init__ self.finish() File "/usr/local/lib/python2.7/dist-packages/roundup/scripts/roundup_server.py", line 683, in finish RoundupRequestHandler.finish(self) File "/usr/lib/python2.7/SocketServer.py", line 713, in finish self.wfile.close() File "/usr/lib/python2.7/socket.py", line 283, in close self.flush() File "/usr/lib/python2.7/socket.py", line 307, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) error: [Errno 32] Broken pipe ---------------------------------------- |
|||
msg6300 | Author: [hidden] (schlatterbeck) | Date: 2018-11-26 17:50 | |
On Mon, Nov 26, 2018 at 11:24:55AM +0000, Paul Spooren wrote: > > The interface works fine except when sending emails by putting entries > to the nosy list. The interface loads until it times out, no matter what > timeout I set in the proxy. > > Receiving emails via mailgw works just fine. > > The error message looks like that: > > File "/usr/lib/python2.7/socket.py", line 307, in flush > self._sock.sendall(view[write_offset:write_offset+buffer_size]) > error: [Errno 32] Broken pipe This looks to me like roundup cannot send back the response to the browser because the browser has closed the connection. This traceback is not from the mail gateway. If the whole procedure takes a *long* time, the browser may have timed out at that point. So if the problem is really with outgoing mail you should check your mail setup: It may well be that your configured mail host is incorrect or not reachable due to firewall or similar issues. You should check that you can connect to the mail gateway from the roundup machine, so if you have configured e.g. [mail] ... host = somewhere.on.the.net ... port = 25 you should check that you can connect to that host on the configured port, e.g. using telnet: % telnet somewhere.on.the.net 25 Trying xxx.xxx.xxx.xxx... Connected to somewhere.on.the.net. Escape character is '^]'. 220 somewhere.on.the.net ESMTP Postfix (Debian/GNU) quit 221 2.0.0 Bye Connection closed by foreign host. Of course the given domain doesn't exist and is an invented example. Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: office@runtux.com |
|||
msg6301 | Author: [hidden] (aparcar) | Date: 2018-11-27 07:20 | |
Hi, thanks for the quick reply. Changing the SMTP port to 25 works, mails are now send and the interface reloads fine. However, with other Python based programs the port 465 is useable with the same mail account. Therefore I figured the TLS causes some problems. Do you have a suggestion on how to debug this any further? Best regards, Paul |
|||
msg6302 | Author: [hidden] (schlatterbeck) | Date: 2018-11-27 09:04 | |
On Tue, Nov 27, 2018 at 07:20:53AM +0000, Paul Spooren wrote: > > Paul Spooren added the comment: > > Hi, thanks for the quick reply. Changing the SMTP port to 25 works, > mails are now send and the interface reloads fine. However, with other > Python based programs the port 465 is useable with the same mail > account. Therefore I figured the TLS causes some problems. Shouldn't it be 485, maybe a Typo? 485 is meant for mail submission. > Do you have a suggestion on how to debug this any further? Check for correct port and check that the port is reachable from the roundup server, no further suggestions. Let me know if it works with 485 Best Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: office@runtux.com |
|||
msg6303 | Author: [hidden] (schlatterbeck) | Date: 2018-11-27 09:18 | |
On Tue, Nov 27, 2018 at 09:04:02AM +0000, Ralf Schlatterbeck wrote: > Shouldn't it be 485, maybe a Typo? > 485 is meant for mail submission. Oops. Submission is 587 not 485 Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: office@runtux.com |
|||
msg6304 | Author: [hidden] (rouilj) | Date: 2018-11-28 02:17 | |
Hello Paul: In message <1543231495.96.0.788709270274.issue2551014@psf.upfronthosting.co.za>, Paul Spooren writes: >The interface works fine except when sending emails by putting entries >to the nosy list. The interface loads until it times out, no matter what >timeout I set in the proxy. > >Receiving emails via mailgw works just fine. > >The error message looks like that: > >127.0.0.1 - - [26/Nov/2018 11:18:18] "POST /support/issue4 HTTP/1.0" 500 - >---------------------------------------- >Exception happened during processing of request from ('127.0.0.1', 46082) >Traceback (most recent call last): > File "/usr/lib/python2.7/SocketServer.py", line 571, in process_request > self.finish_request(request, client_address) > File "/usr/lib/python2.7/SocketServer.py", line 331, in finish_request > self.RequestHandlerClass(request, client_address, self) > File "/usr/lib/python2.7/SocketServer.py", line 654, in __init__ > self.finish() > File >"/usr/local/lib/python2.7/dist-packages/roundup/scripts/roundup_server.py", >line 683, in finish > RoundupRequestHandler.finish(self) > File "/usr/lib/python2.7/SocketServer.py", line 713, in finish > self.wfile.close() > File "/usr/lib/python2.7/socket.py", line 283, in close > self.flush() > File "/usr/lib/python2.7/socket.py", line 307, in flush > self._sock.sendall(view[write_offset:write_offset+buffer_size]) >error: [Errno 32] Broken pipe >---------------------------------------- Sorry you are having an issue (so to speak) with roundup. Assuming your diagnosis is correct, how have you configured outbound email for the tracker? This is configured in the [mail] section of the tracker's config.ini. Can you connect to the configured host and port (try using telnet or netcat to verify a connection)? Are you using tls? If so, do you have a local certificate? Are you using a username and password to authenticate? If you look at the mail logs on the mail server, do you see a connection from the roundup server? If you are logged into the roundup server, do you see a connection from that server to the email port on the mail server (use netstat -an | grep 25 or what value (465 if using tls maybe) you set for the port. If you try to reset your password, is email sent? Are you using the normal nosyreaction.py script to send nosy messages? If so rename/move detectors/nosyreaction.py from your tracker's home directory and restart the roundup server. In this state can you update an issue without it hanging? Hopefully this will give us some idea what's going on. Also you may want to try posting to the roundup-user's mailing list as more people are on that list than there are watching issues. |
|||
msg6360 | Author: [hidden] (schlatterbeck) | Date: 2019-02-20 09:42 | |
Closing, seems changing the port fixed the issue, no further replies. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2019-02-20 09:42:04 | schlatterbeck | set | status: new -> closed resolution: works for me messages: + msg6360 |
2018-11-28 02:17:52 | rouilj | set | nosy:
+ rouilj messages: + msg6304 |
2018-11-27 09:18:18 | schlatterbeck | set | messages: + msg6303 |
2018-11-27 09:04:02 | schlatterbeck | set | messages: + msg6302 |
2018-11-27 07:20:53 | aparcar | set | messages: + msg6301 |
2018-11-26 17:50:10 | schlatterbeck | set | nosy:
+ schlatterbeck messages: + msg6300 |
2018-11-26 11:24:55 | aparcar | create |