Cron spam
-
Just curious. One other change I made when this happened was to check "Disable writing log files to the local disk".
Anyone else have this checked as well.
Nope. Mine is unchecked. But if you're not writing any logs to disk it should be safe to comment that line out from Cron since there's nothing to rotate.
-
I've uninstalled mailreport and arpwatch, which I installed in the last few days prior to getting these emails. Unfortunately, that does not seem to have fixed the situation, or at the least, the uninstall didn't clean up the crontab entry.
I'm going to comment the statement out as well, as I am tired of getting these emails. Hopefully someone can find the package or reason as to why this entry was added so we can figure out the impact of having it commented out.
-
The cron error was there all along – however, arpwatch installs a sendmail-workalike PHP script that actually lets the cron error leave and reach you.
You can install the cron package and remove the newsyslog job. It's not needed. I added some upgrade code a couple weeks ago to remove the job on upgrade to 2.1.x when the next release happens.
-
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=> -
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.
-
So which script generates /etc/crontab? After restarting firewall, all the lines I commented out of crontab are gone.
-
@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>
-
I started receiving these messages too after I installed arpwatch. I removed arpwatch, and still get them.
-
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.
-
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.
-
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.phpThank you ;D
-
@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…
-
@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/1022Still 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)
-
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. -
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).
-
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.
-
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 :) -
rather than hacking at arpwatch.
The damned thing shouldn't have /usr/sbin/sendmail hardcoded in the first place (see the Debian patchset).
-
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.
