Cron messages

[Edwin Ruiz_2]

Hi everybody!

I want to disable mail messages on linux.. my archives on /var/spool/mail are too bigs. how can i do that?

Thanks

[Ian Kidd_1]

I don't believe there's a global parameter to do this. crond mails ANY output from a job called from within cron to the OWNER of the crontab where the job is listed.
So if a job has an output (stout or sterror) and the job is called from root's crontab, then root will get a mail message.

HOWEVER, you can bypass this by redirecting outputs and errors to /dev/null.

For every entry in cron, end it with
> /dev/null 2>&1.

the above means redirect stout to /dev/null and send errors to the same place as stout.
for example, I have a script called mon_ps. I have an entry like
00,15,30,45 * * * * /home/admin/bin/mon_ps > /dev/null 2>&1

complications arise if you're using /etc/cron.daily , /etc/cron.hourly etc. If you do, the only solution I can think of would be to move these files to a different location and call them via crontab

[Olivier Drouin]

Like Ian said there must not be any output from the scripts you run from cron. You have to take care of the logging/rolling.

However, you will still get mail messages. You can forward root's messages to your own box by creating a .forward file in root's home.

If your box is running fine these mails shouldnt get unmanageable unless you have a large number of machines to admin which is another story...

[Cristian Draghici]

You could also add a new job in cron.daily that empties the mailbox

echo "" > /var/spool/mail/username

where username is the user who gets too much mail.


Or you could create a dummy account that does not get mail (redirect to /dev/null) and send the cron messages to that account (see cron man page and the MAILTO environment variable).

Hope this helps

[Jerome Henry]

Hi,

You can also tune main messages source, which could be a good idea, to set up warnings to a higher level, so that you still get important messages from your services, and not all the dummy things that are just normal activity informations.

hth

J

[Elmar P. Kolkman]

cron will post a mail if a command it runs generates output on stdout or stderror. So if you don't want the mail, redirect those to a file or /dev/null, depending on whether you're interested in the messages. I would suggest redirecting stdout to /dev/null and stderr to a logfile or to your mail, because if a command gives errors, it probably needs human intervention.

To clean up your /var/spool/mail, remove the files or empty them. Redirecting the null command is enough:
> /var/spool/mail/

[Steven E. Protter]

You can downgrade the logging level in sendmail.cf to 0 if you want. There should be a loglevel param you can adjust

What you are better off doing however is this:

tar cvf /var/log/maillog /dev/rmt/0m

replace the last part with a tape device or a filesytem

then

> /var/log/maillog

That will zero it out.

Its bad to stop sendmail logging.

If this server is on the public internet this log is a critical audit trail in case someone tries to relay spam off your server.

I have recently had a security flaw exploited in which cgi scripts were used to relay mail. This was done to aol and with the help of the maillog I was able to shut it down.

If I'd had no maillog my only clue would have been aol stopping my mail acceptance, which they did TWO weeks after I shut off the spigot.

I was able to prove to aol that it was an aol customer doing the exploit, submitted my logs and got off the black list.

The point is simple. You need to have a maillog. You need to write a few scripts to scan it for warning signs so you can look at it

SEP