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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
