SeeDk
asked on
cronjobs not writing to /var/spool/mail
This behavior is seen on RHEL6 and 7.
On some servers - cronjobs will write the output to the /var/spool/mail/[USER] directory, with [USER] being the name of the user the cronjob ran under.
On other servers - it does not write any output.
I am struggling to find where the difference in configuration is that is doing this. I have searched online - and most topics are asking on how to disable this output. All the suggestions I've found do not apply to my case. On the cronjobs that are not producing output:
1. There is no "/dev/null" or "2>&1" redirect on any of the cronjobs
2. No MAILTO="" on the users crontab
3. The /etc/crontab file of both the servers with /var/spool/mail output and without are the same:
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:
MAILTO=root
HOME=/
4. The cron script itself is not redirecting output to"/dev/null" or "2>&1"
Where else can I check for the setting that is stopping the output from being created?
On some servers - cronjobs will write the output to the /var/spool/mail/[USER] directory, with [USER] being the name of the user the cronjob ran under.
On other servers - it does not write any output.
I am struggling to find where the difference in configuration is that is doing this. I have searched online - and most topics are asking on how to disable this output. All the suggestions I've found do not apply to my case. On the cronjobs that are not producing output:
1. There is no "/dev/null" or "2>&1" redirect on any of the cronjobs
2. No MAILTO="" on the users crontab
3. The /etc/crontab file of both the servers with /var/spool/mail output and without are the same:
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:
MAILTO=root
HOME=/
4. The cron script itself is not redirecting output to"/dev/null" or "2>&1"
Where else can I check for the setting that is stopping the output from being created?
ASKER
Yes, there is nothing like that under the users crontab.
One of the users has a directory under /var/spool/mail.
The other, the root account, does not.
One of the users has a directory under /var/spool/mail.
The other, the root account, does not.
cron doesn't save output in /var/spool/mail..... it sends MAIL... either to the MAILTO address or to the username
cront executes jobs like:
{command from cron} | mail $MAILTO
(run under the users name}. if MAILTO doesn't exit the mail command will send it to the user it is run under.
They MAY have the effect of putting a file in /var/spool/mail/{user} but only if sendmail is used.
Most other mail systems store the mail in different places. (and even sendmail might be configured to send it to another "mail server").
cront executes jobs like:
{command from cron} | mail $MAILTO
(run under the users name}. if MAILTO doesn't exit the mail command will send it to the user it is run under.
They MAY have the effect of putting a file in /var/spool/mail/{user} but only if sendmail is used.
Most other mail systems store the mail in different places. (and even sendmail might be configured to send it to another "mail server").
So you don't want the output to be created? As is already suggested, this is about mail that is being sent (or not).
Can you verify if you can send mail as root to these users or not? Is there any difference between the servers?
Can you verify if you can send mail as root to these users or not? Is there any difference between the servers?
ASKER
I'm comparing between two servers..A and B. B is creating the output in /var/spool/mail/root and I WANT this output to be created. I would like to get this output working on A.
The differences I see between these are:
On A - 'service sendmail status' returns:
sendmail (pid 4858) is running...
sm-client (pid 4866) is running...
On B - 'service sendmail status' returns:
sendmail: unrecognized service
On A - testing sending email to root : echo "Subject: sendmail test" | sendmail -v root@domain
the result is:
250 2.6.0 <201802231926.w1NJQnTD0582
root@domain.com.. Sent (<201802231926.w1NJQnTD058
Closing connection to exchange.domain.com
And there is nothing appearing in /var/spool/mail/root
On B - testing sending email to root : echo "Subject: sendmail test" | sendmail -v root@domain
The email immediately is sent and appears in /var/spool/mail/root
I am guessing here: email created by serverA is being queued and never delivered. Could it be a misconfiguration with sendmail on this server? Where do I check that?
The differences I see between these are:
On A - 'service sendmail status' returns:
sendmail (pid 4858) is running...
sm-client (pid 4866) is running...
On B - 'service sendmail status' returns:
sendmail: unrecognized service
On A - testing sending email to root : echo "Subject: sendmail test" | sendmail -v root@domain
the result is:
250 2.6.0 <201802231926.w1NJQnTD0582
root@domain.com.. Sent (<201802231926.w1NJQnTD058
Closing connection to exchange.domain.com
And there is nothing appearing in /var/spool/mail/root
On B - testing sending email to root : echo "Subject: sendmail test" | sendmail -v root@domain
The email immediately is sent and appears in /var/spool/mail/root
I am guessing here: email created by serverA is being queued and never delivered. Could it be a misconfiguration with sendmail on this server? Where do I check that?
Ok then you need to use sendmail MTA server on server B.
Sendmail uses the /var/spool/mail/{username}
Sendmail uses the /var/spool/mail/{username}
ASKER
Actually server B is working fine. Server A is the problematic one.
Now I see that server B is actually using postfix when I check what is listening on port 25:
I started postfix and disabled sendmail on server A in hopes that it was properly configured.
Now postfix is started and listening on port 25 the same as in server B. But still emails don't work. I test sending email with:
Then I see in the logs (/var/log/maillog) that sendmail is still being listed as used!
I don't understand how the OS is still trying to use sendmail when the service is stopped?
Now I see that server B is actually using postfix when I check what is listening on port 25:
netstat -ltnp |grep :25
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 3719/master
tcp 0 0 ::1:25 :::* LISTEN 3719/masterI started postfix and disabled sendmail on server A in hopes that it was properly configured.
service sendmail stop
service postfix startNow postfix is started and listening on port 25 the same as in server B. But still emails don't work. I test sending email with:
echo "My message" | mail -s testing root@server.domainThen I see in the logs (/var/log/maillog) that sendmail is still being listed as used!
Feb 26 16:18:13 server sendmail[1582]: w1QLIC8N001582: to=root@server.domain, ctladdr=root (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30233, relay=exchangeserver.domain. [x.x.x.x], dsn=2.0.0, stat=Sent (<201802262118.w1QLIC8N001582@root@server.domain> Queued mail for delivery)I don't understand how the OS is still trying to use sendmail when the service is stopped?
When you install postfix a sendmail alias will be created (lots of software call sendmail hardcoded, so all later (more secure ) mailsystem have a compatible image. postfix, qmail, exim all deliver a sendmail standin. (just the server process is not running sendmail).
"sendmail" is the command that submits a mail to the local maildrop.
every MTA features a sendmail command ( or alias ).
submitting to the local maildrop basically boils to writing a file in a spool directory. this is by design because local mail submission is expected to work even when the local MTA is down.
the sendmail command is named after the sendmail software which it actually evolved from historically ( sendmail was the first MTA with a spool and a demon that would retry failed email and the implementation became reference for others )
--
in your case, there might be an extra mess : you can be using the wrong sendmail command.
type in "ls -l $(which sendmail)" or "sendmail --whateverbogusparameter" in order to see which sendmail command is actually used.
the sendmail alias and in-use MTA should match.
when using the postfix's sendmail, you should see the mail being caught by "postfix/pickup", and then be processed normally. ( cleanup, smtp, qmgr )
if my assupmtion is correct
the above line actually is a sendmail line. sendmail tries to send the email ( and apparently succeeds in this case ) and only spools the mail upon failure. in your case, the corresponding email would be lost forever since the sendmail daemon does not run
every MTA features a sendmail command ( or alias ).
submitting to the local maildrop basically boils to writing a file in a spool directory. this is by design because local mail submission is expected to work even when the local MTA is down.
the sendmail command is named after the sendmail software which it actually evolved from historically ( sendmail was the first MTA with a spool and a demon that would retry failed email and the implementation became reference for others )
--
in your case, there might be an extra mess : you can be using the wrong sendmail command.
type in "ls -l $(which sendmail)" or "sendmail --whateverbogusparameter" in order to see which sendmail command is actually used.
the sendmail alias and in-use MTA should match.
when using the postfix's sendmail, you should see the mail being caught by "postfix/pickup", and then be processed normally. ( cleanup, smtp, qmgr )
if my assupmtion is correct
the above line actually is a sendmail line. sendmail tries to send the email ( and apparently succeeds in this case ) and only spools the mail upon failure. in your case, the corresponding email would be lost forever since the sendmail daemon does not run
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Also, does the user directory exist under /var/spool/mail