Re: [ANNOUNCE] perdition 1.18-rc1
Christian Balzer <[email protected]>
| Newsgroups | gmane.mail.perdition.user |
|---|---|
| Organization | FusionGOL |
| Message-ID | <[email protected]> |
Hello Simon, Oh, 1.18-rc1 made it into sid and thus my test boxes, will give it a whirl later and next week then. ^_^ On Fri, 4 Sep 2009 16:10:52 +1000 Simon Horman wrote: > On Fri, Sep 04, 2009 at 01:15:16PM +0900, Christian Balzer wrote: > > > > Hello Simon, > > > > On Fri, 4 Sep 2009 13:24:41 +1000 Simon Horman wrote: > > > On Fri, Sep 04, 2009 at 11:23:15AM +0900, Christian Balzer wrote: > > > > > > > > Looking at the Changelog I didn't spot anything relating to it, so > > > > would there be a chance to include the feature/fix raised in: > > > > http://lists.vergenet.net/pipermail/perdition-users/2009-January/002074.html > > > > > > > > Or at least adding it to the TODO? > > > > > > > > > > Hi Christian, > > > > > > sorry that one missed the release. It seems like good idea to me. > > > Could you tell me if in the case where you are seeing the problem > > > the client is connecting using plain-text or SSL/TLS ? > > > > > The particular case back then (never happened again, btw) was plain > > text connects. But again, most likely something in the chinese firewall > > caused that behavior. > > The problem that I'm still seeing here as mentioned in: > > http://lists.vergenet.net/pipermail/perdition-users/2008-February/001973.html > > is entirely SSL (pop3s/imaps) based. Sessions/processes will remain in > > the "connect" basically forever. > > Fixing the actual issue (which is likely something SSL related) would > > of course be nice, but some setting that kills off processes that are > > in connect state for a given time has ultimately the same effect and > > is more universally useful. ^_^ > > Agreed on all counts. > > At this stage I am thinking in terms of a idle timeout. > Though I think the default will need to be infinite as > some people like to leave idle IMAP session lying around. > > Those IMAP sessions would not be a affected by an idle timeout specific to the CONNECT state. And a timeout that affects processes in any state would not be very helpful for avoiding resource starvation while providing "eternal" IMAP sessions (which usually see traffic at least every 30 minutes, if I remember my dovecot configs and RFC correctly). Basically a process has no business being in CONNECT for more than 20-60 seconds. --- pp12:~# ps faxw |grep pop3s 15538 ? S 98:04 perdition.pop3s 8027 ? S 0:00 \_ perdition.pop3s: connect 29997 ? S 0:00 \_ perdition.pop3s: connect 3407 ? S 0:00 \_ perdition.pop3s: auth ok 3640 ? S 0:00 \_ perdition.pop3s: auth ok [...] --- 15 total now, there were more than 350 processes before a massive "killall" orgy earlier today. (killall -r perdition.pop3s..connect) Regards, Christian -- Christian Balzer Network/Systems Engineer [email protected] Global OnLine Japan/Fusion Communications http://www.gol.com/ ______________________________________________ Perdition-users mailing list [email protected] http://lists.vergenet.net/listinfo/perdition-users