Cron spam

daq

There are other scripts (installed by packages) in Cron that are either too verbose or produce errors so just commenting out newsyslog is not enough. The ones I found are Snort and Mail Reports, but I suspect this would belong in another forum branch?


 /usr/bin/nice -n20 /usr/local/bin/php -f /usr/local/pkg/snort/snort_check_for_rule_updates.php

Date: Mon, 21 Oct 2013 12:03:44 -0700

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>100%        0%        1%        2%        3%        4%        5%        6%        7%        8%        9%       10%       20%       30%       40%       50%       60%       70%       80%       90%      100%</user=root></logname=root></home=></path=></shell=>


/usr/local/bin/mail_reports_generate.php 0 &

Date: Wed, 16 Oct 2013 08:00:05 -0700

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>Warning: Invalid argument supplied for foreach() in /usr/local/bin/mail_reports_generate.php on line 81</user=root></logname=root></home=></path=></shell=>

jimp

Yes but the packages only affect those who have installed those specific packages. The newsyslog error would affect everyone.

For the package-specific errors, they would be best in separate forum threads.

daq

So which script generates /etc/crontab? After restarting firewall, all the lines I commented out of crontab are gone.

jimp

@daq:

So which script generates /etc/crontab? After restarting firewall, all the lines I commented out of crontab are gone.

pfSense generates it using the "<cron>" tags in config.xml. Install the cron package to manage the cron jobs, do not make manual edits to /etc/crontab</cron>

gossamer

I started receiving these messages too after I installed arpwatch. I removed arpwatch, and still get them.

linkyone

I've been searching a similar issue for a while and this might be related to what I'm experiencing.
Here's what I've discovered:

Firewall temporarily freezes. My Nagios server reports that the /root and /run directory is full, HTTPS times out, and that I have zombie processes. It usually clears itself up after a few minutes but i used to never get these alarms from Nagios before.

I have a syslog server showing multiple instances of things happening with the same timestamp:

(root) CMD (/usr/bin/nice -n20 /usr/local/bin/php -f /usr/local/pkg/snort/snort_check_cron_misc.inc)
(root) CMD (/usr/bin/nice -n20 /usr/local/sbin/expiretable -t 3600 snort2c)
(root) CMD (/etc/rc.filter_configure_sync)

Each of the above is listed over 20 times.

Also, I've subscribed to one email daily of some RRD graphs but when the email is sent from the firewall, I get 18 emails of the same thing!

My packages (all up to date): cron, LCDproc-dev, mailreport, NRPE v2, nut, snort.

I looked through the config.xml file and only see one instance of each cron entry.

Maybe related? I'm no cron expert but I don't believe this is correct so I'd thought I'd share.

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.