Maybe a problem with ssl.
Am 05.09.2013, 12:45 Uhr, schrieb Reindl Harald <[email protected]>:
Am 05.09.2013 12:38, schrieb Harald Leithner:
Pop3d endless loop after monit connects (not on the first check):
Sep 05 12:30:23 HiveTwoB dbmail-pop3d[31700]: [0x7f6482016000]
Notice:[clientbase] client_init(+179): incoming
connection on [127.0.0.1:995] from [127.0.0.1:36748]
Sep 05 12:30:23 HiveTwoB dbmail-pop3d[31700]: [0x7f6482016000]
Notice:[clientbase] client_init(+179): incoming
connection on [127.0.0.1:110] from [127.0.0.1:44965]
It doesn't accept any further connections running commit
f294d43d0aa115e4c4b6c
interesting - f294d43d0aa115e4c4b6c1dbcf72e6cd00badfd1 running here with
mostly POP3 users
at least since 10 minutes as well as on my testserver running 30 minutes
loaded tests
on POP3/IMAP parallel and my PHP-monitoring is also active on both
services
i doubt that it is a new regression but interesting because there where
a bundle
of patches for these problems and my load-tests transferred some TB
mail-data
without any single crash - frustrating that the email stuff is that
complex
[root@testserver:~]$ systemctl status dbmail-pop3d.service
dbmail-pop3d.service - DBMail POP3 Server
Loaded: loaded (/usr/lib/systemd/system/dbmail-pop3d.service; enabled)
Active: active (running) since Do 2013-09-05 12:10:09 CEST; 31min ago
Main PID: 20404 (dbmail-pop3d)
CGroup: name=systemd:/system/dbmail-pop3d.service
└─20404 /usr/sbin/dbmail-pop3d -D
Am 05.09.2013, 11:50 Uhr, schrieb Paul J Stevens <[email protected]>:
On 09/04/2013 05:29 PM, Reindl Harald wrote:
*wait* this one has regressions at least in Roundcube
I'm sorry about that. It's fixed now, with greatly expanded
test-coverage
--
Harald Leithner
ITronic
Vogelweidplatz 12, 1150 Wien, Austria
Tel: +43-1-786 23 88
Fax: +43-1-98 52 077
Mobil: +43-699-123 78 4 78
Mail: [email protected] | itronic.at
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
