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.ht…
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
chibi(a)gol.com Global OnLine Japan/Fusion Communications
http://www.gol.com/