3

I have a problem on CentOS 6.3 system where the crond process tries to unsuccessfully send mail over and over (at least I think this is what its doing) until the OS eventually generates a "too many files open" error. This computer is not connected to a network.

Symptoms

After running overnight, the system produces a "too may files open" error when a user tries to log in.
If I examine the process list after it has been running for a few hours, I see this trio of processes listed several times (the number or repetitions continue growing as time goes on):

CROND
/usr/sbin/sendmail -FCronDaemon -i -odi -oem -i -t ...
/usr/sbin/postdrop -r

Attempted fixes

  • I disabled the postfix process, which seems to be related to the mail sending features
  • I modified /etc/crontab and /etc/anacrontab, and changed the line:

    MAILTO=root
    

    to

    MAILTO=""
    

Neither of these attempted fixes have resolved the problem. It appears that it's actually the postdrop process that is hanging. If I kill it, the other two processes also die. Barring some more elegant solution, my next plan of attack is to replace postdrop with a bash script that does nothing and exits to prevent these processes from accumulating. Any advice is appreciated!

  • Why don't you just remove those commands entirely from cron? – Franz Payer Jan 16 '14 at 18:44
  • Did you try to redirect script output to /dev/null? like: myscript > /dev/null or more "silent" myscript > /dev/null 2>&1 – Wolfy Jan 16 '14 at 19:12
6

I'm guessing the offending cron entry is not in /etc/crontab. MAILTO="" should work, but it has to be in the same file as the cron entry (/etc/cron.d/0hourly, etc).

Also, I'm surprised this is an issue, I think by default if you don't specify an email address for root (/etc/aliases) the mail should get delivered locally.

Alternately/additionally, modify each cron entry to redirect output to /dev/null:

* * * * *  /some/script.sh >/dev/null 2>&1
  • I honestly haven't found which cron entry is the offending one. Thanks for the tip on redirecting the script output. I will give that a try. – KyleL Jan 16 '14 at 19:20
  • You may be able to identify the offending entry from /var/log/cron – Jonathan Nicol Jan 16 '14 at 19:25
2

The problem causing the numerous sendmail and postdrop processes is not that they get started by cron, that is normal behaviour. The problem is that those don't terminate almost immediately as usual but continue to run, or rather hang resulting an enormously long process list:

/usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root
/usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root
/usr/sbin/postdrop -r
/usr/sbin/postdrop -r
/usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root
/usr/sbin/postdrop -r
/usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root
/usr/sbin/postdrop -r

As the manual explains: the postdrop(1) command creates a file in the maildrop directory and copies its standard input to the file.

The reason the sendmail and associated postdrop processes were hanging in our environment was because the file-system with the maildrop directory /var/spool/postfix had become read-only. Since the whole of /var/ was read-only no errors were recorded in the logs either.

Check /proc/mounts for a read-only file system and try to resolve with mount -o remount,rw /var.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.