3 Sep
2009
3 Sep
'09
1:10 p.m.
Hi,
I'm happy to announce the release of 1.18-rc1,
with a view to turning this into 1.18.i Please test.
There are numerous changes since 1.18. Perhaps the most significant
being the inclusion of IPv6 support which is in part provided
by vanessa-logger 0.0.8, which was also released today.
A complete list of changes is available in the ChangeLog,
the 1.18-rc1 portion of which was generated from the logs
in mercurial.
http://www.vergenet.net/linux/perdition/ChangeLog.shtml
Perdition 1.18-rc1 and the vanessa libraries that it depends on
are available from:
http://www.vergenet.net/linux/perdition/download/1.18-rc1/
3 Sep
3 Sep
1:50 p.m.
On Thu, Sep 03, 2009 at 11:10:37PM +1000, Simon Horman wrote:
Hi,
I'm happy to announce the release of 1.18-rc1,
with a view to turning this into 1.18.i Please test.
There are numerous changes since 1.18. Perhaps the most significant
being the inclusion of IPv6 support which is in part provided
by vanessa-logger 0.0.8, which was also released today.
The IPv6 code is in vanessa-socket not vanessa-logger,
which also had version 0.0.8 released today.
A complete list of changes is available in the
ChangeLog,
the 1.18-rc1 portion of which was generated from the logs
in mercurial.
http://www.vergenet.net/linux/perdition/ChangeLog.shtml
Perdition 1.18-rc1 and the vanessa libraries that it depends on
are available from:
http://www.vergenet.net/linux/perdition/download/1.18-rc1/
4 Sep
4 Sep
2:23 a.m.
Hello Simon,
good to see IPv6 coming in, it will be needed here next year at the latest.
^.^
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?
Regards from the cloudy Tokyo,
Christian
--
Christian Balzer Network/Systems Engineer
chibi(a)gol.com Global OnLine Japan/Fusion Communications
http://www.gol.com/
3:24 a.m.
On Fri, Sep 04, 2009 at 11:23:15AM +0900, Christian Balzer wrote:
Hello Simon,
good to see IPv6 coming in, it will be needed here next year at the latest.
^.^
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?
Regards from the cloudy Tokyo,
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 ?
Thanks
4:15 a.m.
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:
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. ^_^
Regards,
Christian
--
Christian Balzer Network/Systems Engineer
chibi(a)gol.com Global OnLine Japan/Fusion Communications
http://www.gol.com/
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 ?
6:10 a.m.
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:
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.
On Fri, Sep 04, 2009 at 11:23:15AM +0900,
Christian Balzer wrote:
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. ^_^
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 ?
6:36 a.m.
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:
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/
Hello Simon,
On Fri, 4 Sep 2009 13:24:41 +1000 Simon Horman wrote:
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.
On Fri, Sep 04, 2009 at 11:23:15AM +0900,
Christian Balzer wrote:
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. ^_^
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 ?
7:19 a.m.
On Fri, Sep 04, 2009 at 03:36:22PM +0900, Christian Balzer wrote:
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:
Understood. I was a bit confused about when you wanted the time-out to
occur.
It should just really be a matter of digging through a few different
levels of calls to io functions so that a time-out can be passed by
the caller - which will know what stage the connection is at - rather
than they current arrangement of always using a global value.
I noisy but simple change I suspect. I'll see if I can get a patch together
shortly.
On Fri, Sep 04, 2009 at 01:15:16PM +0900,
Christian Balzer wrote:
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.
Hello Simon,
On Fri, 4 Sep 2009 13:24:41 +1000 Simon Horman wrote:
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.
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. ^_^
6:37 a.m.
On Fri, Sep 04, 2009 at 04:10:52PM +1000, Simon Horman wrote:
On Fri, Sep 04, 2009 at 01:15:16PM +0900, Christian
Balzer wrote:
Hi,
after looking over the code briefly I see that there is a timeout that
can be used, using the timeout configuration option. However it is global
and affects all reads. Is your idea for a timeout that only takes affect
before users are authenticated?
Hello Simon,
On Fri, 4 Sep 2009 13:24:41 +1000 Simon Horman wrote:
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. On Fri, Sep 04, 2009 at 11:23:15AM +0900,
Christian Balzer wrote:
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. ^_^
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 ?
5361
days inactive
5362
days old
8 comments
2 participants
participants (2)
-
Christian Balzer -
Simon Horman