logs archiveIRC Archive / Freenode / #exim / 2015 / July / 29 / 1
jgh_
hs12: remarkably little noise from the release. I was scared Armageddon would happen
hs12
jgh_: Everybody is on holidy ... no traffic and no admins installing new software :)
s/dy/day/
jgh_
all gone to Marbella :-]
hs12
:)
It seems that ip_recv needs to handle EAGAIN to avoid the spamd 'resource anavailable problem'. I'm testing it on my server.
jgh_
yeah, that was my thought. Also check to see if other users of it could benefit from going nodelay... there's half a dozen, unfortunately one is the main input...
fortunately just leaving the nodelay aspect as-is won't break anything (I think)
hs12
I'm lost... what are your talking about with "no delay"? I just put there a small loop for (rc < 0 && errno == EAGAIN).
jgh_
the problem happens, I think because of a bug in Linux select. See manpage. Luckily, if the following recv is on a nodelay socket (and the spamd specific one is), you then get EAGAIN/EWOULDBLOCK (must test both for portability, though identical value on Linux)
+/* Linux select(2) is buggy according to the manpage and can spuriously
+return ready for an fd. The following recv(2) then returns EAGAIN since
+we are nonblocking. XXX check nonblocking for all callers
+*/
poll is equally buggy. I did wonder about SO_RECVTIMEO.
hs12
Hm, I thought the select() detects activity on the socket and returns. The following recv() gets interrupted before reading anything because of the signal. You thing, the select() returns a false positive, because it was interrupted already? The following recv() 'duplicates' that errno, because there isn't anything to read yet? Hm, I have to find a way to check that.
Yup, in normal operation, if I just loop around the rc = recv() ... I got already 11428413 iterations until we read anything. I didn't expect that the socket was opened non-blocking.
jgh_
can you get an strace of the symptom? then we see if it's the select
         

hs12
jgh_: Sent via email.
jgh_
lines 1297 to 1306 look to be the event
we dropped out of the select to handle the signal, and didn't go back into select again
hs12
Another approach: the spamd socket, after sending it's shutdown SHUT_WR. Cannot we fcntl to BLOCKING now, can we? The timeouts should work anyways, shouldn't they?
jgh_
not in the face of this bug, no. The spurious return from select-with-timeout would leave us blocked indefinitely
cebka
RECVTIMEO is not very portable AFAIR
jgh_
I did wonder... and it's been hard-coded into the proxy handling
Steves lists them, so they've been around a while. Do you have a ref. for the (non)portability?
Stevens 1990
Circuitsoft
Hello. I'm trying to configure exim4 to only deliver email for automated systems (mdadm, cron, etc), so I would like my installation to rewrite the from: and to: on all emails.
Is that possible?
So, all email would come from itappmonrobot@mydomain.com and be delievered to it.mailing.list@mydomain.com
mydomain.com MX points to gmail.
And there is an account for itappmonrobot.
notkoos
Circuitsoft: exim's 'rewrite' rules can do this: http://www.exim.org/exim-html-current/doc/html/spec_html/ch-address_rewriting.html (if you really need to rewrite headers) - you could set a special destination for all mail with the redirect router: http://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_redirect_router.html
hs12
jgh_: one question? about src/ip.c and the select() loop in fd_ready() around line 487.
jgh_: done :)
jgh_
hs12: we ought to get EINTR for your signal... but we don't
hs12
jgh_: I instrumented the select loop a bit, and watching what happens if I hammer the process with USR1 signals:
It's about that way: the select gets interrupted about 3 times, errno is EINTR and thus the loop continues. And then, suddenly the loop is left (no signal at all) and recv() gets called:
2015-07-29 23:00:42 [20998] 1ZKYSu-0005Sg-FF HS12: rc:-1 after 1s 4:Interrupted system call
2015-07-29 23:00:42 [20998] 1ZKYSu-0005Sg-FF HS12: re-select with a timeout 120
2015-07-29 23:00:42 [20998] 1ZKYSu-0005Sg-FF HS12: rc:-1 after 1s 4:Interrupted system call
2015-07-29 23:00:42 [20998] 1ZKYSu-0005Sg-FF HS12: re-select with a timeout 120
2015-07-29 23:00:42 [20998] 1ZKYSu-0005Sg-FF spam acl condition: error reading from spamd socket: i=-1 11/Resource temporarily unavailable
The output is from my instrumentation, the rc:-1 ... line is in the loop, unconditionally printing the rc and errno when the select() returns. The re-select line is written in the if (rc < 0 && errno == EINTR) block.
not so unconditionally, only if errno is set.
It seems that indeed select() returns successfully, errno set to 0 and the wanted fd in the marked as worth reading. Because there is no other way to leave the do { select() } while ... loop, except a timeout, which we didn't hit.
(Action) believes that he found a solution, but for now it's late and tomorrow it will be tested on a production system
« prev next »