my guess is still STARTTLS while i can not reproduce it with STARTTLS on localhost for now (debug-backend a hour ago extended to chose connection mode)
our production machines behind dovecot-proxy are stable
with f294d43d0aa115e4c4b6c1dbcf72e6cd00badfd1 and at least
POP3 has permanently load because i realized the customer
with 36 accounts and exchange connector does not check
every 3 minutes for new mails, he loops, after the last
account was checked it starts from new - most likely the
reason why we could reproduce the memory corruption easy
in combination with the other mixed load on POP3/IMAP
[root@mail:~]$ systemctl status dbmail-imapd.service
dbmail-imapd.service - DBMail IMAP Server
Loaded: loaded (/usr/lib/systemd/system/dbmail-imapd.service; enabled)
Active: active (running) since Do 2013-09-05 12:31:49 CEST; 1 day 12h ago
Main PID: 8467 (dbmail-imapd)
CGroup: name=systemd:/system/dbmail-imapd.service
└─8467 /usr/sbin/dbmail-imapd -D
[root@mail:~]$ 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:31:49 CEST; 1 day 12h ago
Main PID: 8468 (dbmail-pop3d)
CGroup: name=systemd:/system/dbmail-pop3d.service
└─8468 /usr/sbin/dbmail-pop3d -D
[root@mail:~]$ systemctl status dbmail-timsieved.service
dbmail-timsieved.service - DBMail SIEVE Server
Loaded: loaded (/usr/lib/systemd/system/dbmail-timsieved.service; enabled)
Active: active (running) since Do 2013-09-05 12:31:49 CEST; 1 day 12h ago
Main PID: 8470 (dbmail-timsieve)
CGroup: name=systemd:/system/dbmail-timsieved.service
└─8470 /usr/sbin/dbmail-timsieved -D
Am 06.09.2013 20:07, schrieb Harald Leithner:
> Even imapd has the same? problem:
>
> time(NULL) = 1378490616
> read(130, 0x7f3c9bb34003, 5) = -1 EAGAIN (Resource temporarily
> unavailable)
> poll([{fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=130,
> events=POLLIN|POLLOUT}, {fd=11, events=POLLIN},
> {fd=71, events=POLLIN}, {fd=98, events=POLLIN}, {fd=25, events=POLLIN},
> {fd=61, events=POLLIN}, {fd=14,
> events=POLLIN}, {fd=45, events=POLLIN}, {fd=191, events=POLLIN}, {fd=107,
> events=POLLIN}, {fd=21, events=POLLIN},
> {fd=24, events=POLLIN}, {fd=101, events=POLLIN}, {fd=35, events=POLLIN},
> {fd=120, events=POLLIN}, {fd=65,
> events=POLLIN}, {fd=105, events=POLLIN}, {fd=97, events=POLLIN}, {fd=47,
> events=POLLIN}, {fd=57, events=POLLIN},
> {fd=50, events=POLLIN}, {fd=43, events=POLLIN}, {fd=20, events=POLLIN},
> {fd=19, events=POLLIN}, {fd=27,
> events=POLLIN}, {fd=79, events=POLLIN}, {fd=42, events=POLLIN}, {fd=121,
> events=POLLIN}, {fd=55, events=POLLIN},
> {fd=192, events=POLLIN}, ....], 55, 1686) = 1 ([{fd=130, revents=POLLOUT}])
> time(NULL) = 1378490616
> read(130, 0x7f3c9bb34003, 5) = -1 EAGAIN (Resource temporarily
> unavailable)
> poll([{fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=130,
> events=POLLIN|POLLOUT}, {fd=11, events=POLLIN},
> {fd=71, events=POLLIN}, {fd=98, events=POLLIN}, {fd=25, events=POLLIN},
> {fd=61, events=POLLIN}, {fd=14,
> events=POLLIN}, {fd=45, events=POLLIN}, {fd=191, events=POLLIN}, {fd=107,
> events=POLLIN}, {fd=21, events=POLLIN},
> {fd=24, events=POLLIN}, {fd=101, events=POLLIN}, {fd=35, events=POLLIN},
> {fd=120, events=POLLIN}, {fd=65,
> events=POLLIN}, {fd=105, events=POLLIN}, {fd=97, events=POLLIN}, {fd=47,
> events=POLLIN}, {fd=57, events=POLLIN},
> {fd=50, events=POLLIN}, {fd=43, events=POLLIN}, {fd=20, events=POLLIN},
> {fd=19, events=POLLIN}, {fd=27,
> events=POLLIN}, {fd=79, events=POLLIN}, {fd=42, events=POLLIN}, {fd=121,
> events=POLLIN}, {fd=55, events=POLLIN},
> {fd=192, events=POLLIN}, ....], 55, 1686) = 1 ([{fd=130, revents=POLLOUT}])
>
> And today I checked that sieve day hangs after unkown time and does not
> accept new connections, I only noticed this
> problem one time after upgrading to 3.1.x. Till this upgrade sieved was
> really stable.
>
> Anything I could help?
>
> Am 05.09.2013, 14:05 Uhr, schrieb Pavlo Lavrenenko <[email protected]>:
>
>> On 09/05/2013 02:51 PM, Paul J Stevens wrote:
>>> On 09/05/2013 01:19 PM, Harald Leithner wrote:
>>>> happend again strace:
>>>>
>>>> write(15, "45c5da7ae15b84b5df1b8ee22527\r\n11"..., 18673) = -1 EAGAIN
>>>> (Resource temporarily unavailable)
>>>
>>> Should we add a loop protection here? Why does the kernel insist that
>>> the socket is ready for writing, while returning EAGAIN when written to?
>>> I wonder...
>>>
>>
>> Well, DBMail does set O_NONBLOCK flag on pipe file handles, so its always
>> ready for writing...
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
