How to stop the deluge of entries in /var/log files?

Craig White craigwhite at azapple.com
Thu Feb 4 20:09:18 MST 2010


On Thu, 2010-02-04 at 18:15 -0700, joe at actionline.com wrote:
> > On Thu, 2010-02-04 at 17:31 -0700, joe at actionline.com wrote:
> >> While fixing a 'syslog' problem on one of my systems, I just discovered
> >> that on one of my other systems, there has been a deluge of identical
> >> (redundant) entries (for two different topics), each going into several
> >> different files in /var/log and I can't figure out how or find where to
> >> put a stop to it.
> >>
> >> Here are just a half-dozen example lines of each topic showing that the
> >> exact same entry for one going in every single minute 24/7 ... that is
> >> 60*24=1440 entries every single day for one and a different schedule for
> >> the other.
> >>
> >> Example #1:
> >> Feb  4 04:11:01 localhost crond[3125]: (root) CMD (
> >> /usr/share/msec/promisc_check.sh)
> >> Feb  4 04:12:01 localhost crond[3134]: (root) CMD (
> >> /usr/share/msec/promisc_check.sh)
> >> Feb  4 04:13:01 localhost crond[3143]: (root) CMD (
> >> /usr/share/msec/promisc_check.sh)
> >> Feb  4 04:14:01 localhost crond[3152]: (root) CMD (
> >> /usr/share/msec/promisc_check.sh)
> >> Feb  4 04:15:01 localhost crond[3161]: (root) CMD (
> >> /usr/share/msec/promisc_check.sh)
> >> Feb  4 04:16:01 localhost crond[3170]: (root) CMD (
> >> /usr/share/msec/promisc_check.sh)
> >>
> >> Example #2:
> >> Feb  4 04:02:11 localhost msec: Wrong permissions of
> >> /var/log/lpr/info.4.gz: should be 640
> >> Feb  4 04:02:11 localhost msec: Wrong permissions of
> >> /var/log/daemons/info.3.gz: should be 640
> >> Feb  4 04:02:11 localhost msec: Wrong permissions of
> >> /var/log/news/news.notice.3.gz: should be 640
> >> Feb  4 04:02:11 localhost msec: Wrong permissions of
> >> /etc/rc.d/init.d/avahi-daemon: should be 744
> >> Feb  4 04:02:11 localhost msec: Wrong permissions of
> >> /var/log/cron/warnings.5.gz: should be 640
> >> Feb  4 04:02:11 localhost msec: Wrong permissions of
> >> /var/log/cups/error_log: should be 640
> >>
> >> How can I stop this?
> > ----
> > fix the problems...
> > (fix the permissions...
> > chmod 640 /var/log/lpr/*
> > chmod 640 /var/log/daemons/*
> > chmod 640 /var/log/news/*
> > chmod 744 /etc/rc.d/init.d/avahi-daemon
> > chmod 640 /var/log/cups/*
> > )
> >
> > as for Feb  4 04:16:01 localhost crond[3170]: (root) CMD (
> > /usr/share/msec/promisc_check.sh)
> >
> > I'd probably check with your particular distribution for the recommended
> > fix and/or bug report it.
> >
> > Craig
> 
> Thanks Craig.
> 
> Re the permissions item, I neglected to say that the reported files and
> directories are already set with the correct permissions, but those claims
> of "wrong permissions" keep on coming anyway.
----
that defies my understanding of things so I struggle to believe it.

what is output of say...
ls -l /var/log/lpr
?
----
> 
> Re the other item, I have searched and searched, but I can't find where
> the crond action is being generated.  The problem has not always been
> happening, I just discovered that it started at the end of December 09.
> And, this problem does not occur on two other systems that have the exact
> same distro / same version installed at the same time.
> 
> I've searched for and grep'd through every file I could find that has
> 'cron' or 'crond' and I can't find any reference to 'promisc_check.sh'
> and neither 'crontab' (nor any other file I can find has any setting for
> every minute.  I find only hourly, daily, weekly, monthly:
> 
> 01 * * * * root run-parts /etc/cron.hourly
> 02 4 * * * root run-parts /etc/cron.daily
> 22 4 * * 0 root run-parts /etc/cron.weekly
> 42 4 1 * * root run-parts /etc/cron.monthly
----
You might want to see what is actually in those files...
(/etc/cron.hourly/*, etc.) and potentially edit or remove them as
useful. I suspect the ones that are making you crazy are in the
cron.hourly

Clearly the 'promisc_check.sh' is in the hourly and that would seem to
be a safety check from your distro and it is reporting to syslog which
actually makes a lot of sense and I would probably just leave it alone
(i.e. keep running the 'promiscuity check' every hour but that's just
me)

The permissions check are probably part of logrotate and it's possible
that some of the logrotate functions aren't setting the permissions
right when it creates/rotates logs (note the 4:02 time) so you might
want to check /etc/logrotate.d/* stuff but again, I think this is the
kind of thing that your particular distribution should be aware of and
make fixes for unless this is because you already 'fixed'.

In summary, I would want to fix the permissions issues being reported
but I'd probably leave the safety checks alone.

Craig


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the PLUG-discuss mailing list