[Dovecot] 1.0.rc10 in inetd mode
Hey.. I'm finding that I can force dovecot (setup in inetd mode) into a wedged state by spamming it with carrage returns. As I've not had enough time to familiarize myself with the code.. I thought I'd ping the list before 1.0 is christened.
-Phil.Sorry, I just realized my problem description sucked in describing how to reproduce this. I've setup xinetd to start imap-login. I was connecting to the imaps port with 'openssl s_client -connect ..' pressing enter until the server process ended the session. The 1st and 2nd, times everything appears to work... though with slightly different output. The 3rd time the connection opens, but no output is received and the connection is inoperable as well as any following connection to that server.
I verified that the non ssl session has the same problem, and that the stand-alone server mode does not have this problem, so it's isolated to the inetd mode.
Sorry.. hope this helps..
-Phil.Phil Oleson wrote:
Hey.. I'm finding that I can force dovecot (setup in inetd mode) into a wedged state by spamming it with carrage returns. As I've not had enough time to familiarize myself with the code.. I thought I'd ping the list before 1.0 is christened.
-Phil.
Guess I'll keep responding to myself, in order to keep a trail for this issue. as noone else has chimed in with a suggestion.
Tried the to get the same results out of a FreeBSD box and though it failed similarly on the 1st and 2nd connections, the 3rd connect failed slightly differently with: 'Fatal: EOF while reading environment from master' and disconnects, while on the RHEL4 box where the orignal test was run, hangs with no error.
Guess I need to figure out the istream implementation in place for dovecot.
-Phil.Phil Oleson wrote:
Sorry, I just realized my problem description sucked in describing how to reproduce this. I've setup xinetd to start imap-login. I was connecting to the imaps port with 'openssl s_client -connect ..' pressing enter until the server process ended the session. The 1st and 2nd, times everything appears to work... though with slightly different output. The 3rd time the connection opens, but no output is received and the connection is inoperable as well as any following connection to that server.
I verified that the non ssl session has the same problem, and that the stand-alone server mode does not have this problem, so it's isolated to the inetd mode.
Sorry.. hope this helps..
-Phil.Phil Oleson wrote:
Hey.. I'm finding that I can force dovecot (setup in inetd mode) into a wedged state by spamming it with carrage returns. As I've not had enough time to familiarize myself with the code.. I thought I'd ping the list before 1.0 is christened.
-Phil.
On Thu, 19 Oct 2006, Phil Oleson wrote (originally top-posted):
Phil Oleson wrote:
Sorry, I just realized my problem description sucked in describing how to reproduce this. I've setup xinetd to start imap-login. I was connecting to the imaps port with 'openssl s_client -connect ..' pressing enter until the server process ended the session. The 1st and 2nd, times everything appears to work... though with slightly different output. The 3rd time the connection opens, but no output is received and the connection is inoperable as well as any following connection to that server.
I verified that the non ssl session has the same problem, and that the stand-alone server mode does not have this problem, so it's isolated to the inetd mode.
Sorry.. hope this helps..
Guess I'll keep responding to myself, in order to keep a trail for this issue. as noone else has chimed in with a suggestion.
Tried the to get the same results out of a FreeBSD box and though it failed similarly on the 1st and 2nd connections, the 3rd connect failed slightly differently with: 'Fatal: EOF while reading environment from master' and disconnects, while on the RHEL4 box where the orignal test was run, hangs with no error.
Guess I need to figure out the istream implementation in place for dovecot.
Coincidentally, I've just been trying rc10 on Linux/FC5 both in daemon mode where it behaved pretty well (a few issues unrelated to the above), and in xinetd mode where it immediately displayed various of peculiar behaviours on call set-up. (I wasn't even attempting any "CR-slamming".)
I haven't had the chance to investigate, or even properly record, this xinetd aspect. And local priority juggling means, sadly, that I probably won't be able to pursue it any time soon. But just to let you know you are not alone. Count this merely as a "+1" for observing significantly poorer behaviour under "xinetd".
But I also note and respect the author's: http://wiki.dovecot.org/InetdInstall
which says right at the top: "Preferred way to run Dovecot is to just start the dovecot binary..."
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :
participants (2)
-
David Lee
-
Phil Oleson