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 <sa...@portaone.com>:
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...
--
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: leith...@itronic.at | itronic.at
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
