Ansgar Burchardt wrote:
On my system, root's mail is redirected to my own account (mwg)
through /etc/aliases :
root: mwg
so, the testcase is to submit at/batch job under root, and then you
don't get its output when you use courier-mta as sendmail.
Can you please try to send mail directly using sendmail?
$ echo "Subject: foo\n\nbar" | /usr/sbin/sendmail -i root
This should send a mail to root. Please try it as both root and your
usual user account. You can also try sending mail as root to your own
account.
Does this produce any error messages? Or does something show up in the
log files?
sendmail run by hand works well in all 4 cases
({mwg,root} -> {mwg,root})
I would also say, that the script submitted as root's at/batch job
is run and does what it has been told. Just don't get its output by
mail, every time with courier-mta.
...
Finally, I dared to strace atd and its subprocesses, and found the
difference between sendmail run for root and non-root user.
Being run from atd, sendmail process does not have open stdout and
stderr file descriptors. And courier's sendmail, being run for ordinary
user, checks that (fcntl(..., F_GETFD)) and reopens them to /dev/null.
For root user, it does not check/reopen them, so FDs 1 and 2 get
reused for other file descriptors (probably, in dlopen, as a socket
to connect to nscd service, and so on), and certain hell ensues as a
result.
As you may imagine, sendmail run from the interactive terminal session
inherits open stdout/stderr and so probably does not have these issues
at all.
Don't know what is the root cause. Probably it has something to do with
O_CLOEXEC flag. Don't know what would be simpler, to fix that at
courier-mta level, or at atd's (just ensure we have stdout and stderr
open without CLOEXEC before running sendmail).
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
