Cron spam

dgcom

If anyone still interested to know why cron is spamming, I posted an explanation (and workaround) here.

In short - package arpwatch installs /sbin/sendmail (as a link to php script to send email). Cron looks for sendmail and if found, starts sending out reports. Can be disabled by adding empty MAILTO to crontb file.

Mr. Jingles

@dgcom:

If anyone still interested to know why cron is spamming, I posted an explanation (and workaround) here.

In short - package arpwatch installs /sbin/sendmail (as a link to php script to send email). Cron looks for sendmail and if found, starts sending out reports. Can be disabled by adding empty MAILTO to crontb file.

I had the same problem: installed arpwatch, immediately was flooded with this crap:


 Subject: Cron <root@wallstreet> /etc/rc.filter_configure_sync

X-Cron-Env: <shell= bin="" sh="">
X-Cron-Env: <path= etc:="" bin:="" sbin:="" usr="" sbin="">
X-Cron-Env: <home= var="" log="">
X-Cron-Env: <logname=root>
X-Cron-Env: <user=root>
0 addresses deleted.</user=root></logname=root></home=></path=></shell=></root@wallstreet>

I uninstalled arpwatch, but the crap remained flooding in.

For now I have done what you tipped:

Just a quick update. Adding
MAILTO=""
```to /etc/crontab resolved the issue.

But now I remain with: shouldn't it be better to fix the cause? What if cron wants to send out mails in the future?

Shouldn't there be something (sendmail?) uninstalled that arpwatch apparently forgot to remove on uninstallation?

My cron currently shows this:


 1,31 0-5 * * * root /usr/bin/nice -n20 adjkerntz -a   

1   3   *   *   *   root   /usr/bin/nice -n20 /etc/rc.update_bogons.sh   

*/60   *   *   *   *   root   /usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 sshlockout   

1   1   *   *   *   root   /usr/bin/nice -n20 /etc/rc.dyndns.update   

*/60   *   *   *   *   root   /usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 virusprot   

30   12   *   *   *   root   /usr/bin/nice -n20 /etc/rc.update_urltables   

0   6   *   *   *   root   /usr/local/bin/mail_reports_generate.php 0 &   

0,15,30,45   *   *   *   *   root   /etc/rc.filter_configure_sync   

50   *   *   *   *   root   /usr/bin/nice -n20 /home/badips/pfiprep >> /home/badips/download.log 2>&1   

*/1   *   *   *   *   root   /usr/local/pkg/servicewatchdog_cron.php   

*/1   *   *   *   *   root   /usr/local/pkg/vnstat2/vnstat2.sh   

*/5   *   *   *   *   root   /usr/bin/nice -n20 /usr/local/bin/php -f /usr/local/pkg/snort/snort_check_cron_misc.inc   

 42   3,15   *   *   *   root   /usr/bin/nice -n20 /usr/local/bin/php -f /usr/local/pkg/snort/snort_check_for_rule_updates.php

Thank you ;D

dgcom

@Hollander:

But now I remain with: shouldn't it be better to fix the cause? What if cron wants to send out mails in the future?

Shouldn't there be something (sendmail?) uninstalled that arpwatch apparently forgot to remove on uninstallation?

It would be great if the original cause can be fixed, but with current state of packager support I do not have much hope for it.

Workaround is easy or you can figure out which app is spamming you and try redirecting its output somewhere else to avoid it being picked up by cron…

doktornotor

@dgcom:

@Hollander:

But now I remain with: shouldn't it be better to fix the cause? What if cron wants to send out mails in the future?

Shouldn't there be something (sendmail?) uninstalled that arpwatch apparently forgot to remove on uninstallation?

It would be great if the original cause can be fixed, but with current state of packager support I do not have much hope for it.

Workaround is easy or you can figure out which app is spamming you and try redirecting its output somewhere else to avoid it being picked up by cron…

Better late than never… arpwatch package will now at least clean up after itself on uninstall, ~~once this PR is merged:~~ https://github.com/pfsense/pfsense-packages/pull/1022

Still need to see about a proper fix, i.e., not install sendmail-like crap in the first place. Shouldn't be required by the package at all.

EDIT: Merged. That was really fast. ;D 8)

dgcom

I do not really mind having command line mailer - might be useful for other automation on the box…
I think, bigger issue is with cron jobs setup causing emails without easy way to change that behavior.

doktornotor

The CLI mailer is /usr/local/bin/mail.php. Alas there's no way to pass sendmail path to arpwatch without patching and recompiling (Debian has one patch, probably others as well.) Sendmail is something that per developers will never make its way in; repeatedly stated.

For people here who still get spam even after uninstalling arpwatch, simply delete /usr/sbin/sendmail (that's what the package now does on uninstall).

jimp

mail.php works differently than arpwatch expects, which is why I put sm.php in there to be a "sendmail work-alike" which is what it needs/wants.

The cron spam is not really caused by the presence of sm.php but by sloppy handling of cron jobs added by other packages that were unseen because the cron errors had nowhere to go without a mailer present. With sm.php linked as sendmail, cron could send e-mail like it wanted so it passed along errors when they popped up.

Fixing the various cron jobs in other packages to either send their output to /dev/null or to fix the errors reported in the body of the cron messages is the correct way to handle the problem, rather than hacking at arpwatch.

dgcom

@jimp:

Fixing the various cron jobs in other packages to either send their output to /dev/null or to fix the errors reported in the body of the cron messages is the correct way to handle the problem, rather than hacking at arpwatch.

Exactly! That is something I fully agree on.
I would still add a simple text box for MAILTO field, possibly in cron package - for easier control if bad packages persist :)

doktornotor

@jimp:

rather than hacking at arpwatch.

The damned thing shouldn't have /usr/sbin/sendmail hardcoded in the first place (see the Debian patchset).

jimp

It shouldn't – but that still doesn't solve the problem here (cron spam). It's only relevant to arpwatch. Even if arpwatch supported some other mail mechanism, should we decide to include this script in base as sendmail or if some other package uses it the crontab spam would still occur.

(Re)moving sendmail to alleviate cron spam doesn't fix anything, it only stops the notifications from letting the admin know that shit's broken. Fixing the broken shit is the cure.