Cron spam
-
I suspect Mailreport as well. I've had Snort installed since I set up pfSense, but Cron spam started after I installed Mailreport.
I noticed that Mailreports has a new version that should fix this issue. Changelog says
When sending an e-mail report, do not generate output, otherwise it will generate a message from cron.
I'm still getting Cron spam with the new version so update must've fixed something else.
I'll try uninstalling it and post back here.
-
I started getting this today. It started after I installed nmap, mtr-nox11, arpwatch, and arping. I don't have snort or the mail package installed.
-
I commented this line out of /etc/crontab and spam seems to have stopped:
#0 * * * * root /usr/bin/nice -n20 newsyslog -
My concern is that by commenting that out is something else not working as well.
-
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.
-
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).
