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.


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):

/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:




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? Commented Jan 16, 2014 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
    Commented Jan 16, 2014 at 19:12

2 Answers 2


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
    Commented Jan 16, 2014 at 19:20
  • You may be able to identify the offending entry from /var/log/cron Commented Jan 16, 2014 at 19:25

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .