Bug 44643 - nastygrams from cron
Summary: nastygrams from cron
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sysstat   
(Show other bugs)
Version: 7.3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Preston Brown
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2001-06-14 23:09 UTC by Michal Jaegermann
Modified: 2007-04-18 16:33 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-31 14:31:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michal Jaegermann 2001-06-14 23:09:42 UTC
Description of Problem:
On my test system I found in 'root' mail this:

Subject: Cron <root@toaster> run-parts /etc/cron.daily


rm: `/var/log/sa' is a directory

Checking closer it looks like that the last line of /usr/lib/sa/sa2
script is responsible.  The complaint above will happen only on some
"strange" occasions but the following change to the line in question:

find /var/log/sa \( -name 'sar?*' -o -name 'sa?*' \) -mtime +7 -exec rm -f
{} \;

would prevent that from happening.

Comment 1 Preston Brown 2001-07-02 14:36:15 UTC

On what occasion could this happen?  I can't seem to trigger repeat behaviour and I'm 
not sure what your fix accomplishes besides matching longer filenames?

Comment 2 Michal Jaegermann 2001-07-02 15:29:13 UTC
This error happens when /var/log/sa exists ('sysstat' package was
already installed), and cron runs (think 'ancron') but no information
was recently collected for whatever reasons (you just installed the thing, or
it was turned off recently because of something, or this is a laptop
which was dormant for two weeks, or ... ).

You can likely provoke it by turning off 'systat', "rewinding" timestamp
on /var/log/sa with 'touch -d ...' and waiting for cron. :-)

The point of a proposed change is exactly to match longer names as then
/var/log/sa directory itself will not match but data files with names
like 'sa<something>' and 'sar<something>' will do - if they exist.
Actually a pattern 'sa?*' should be good enough for everything.
Normally you do not try to remove /var/log/sa because if 'sysstat'
is active then it has a recent timestamp and not because you did not
match the name.

This is rather minor and it can be dismissed with "Do not mess with toys
you do not have a business with" but this seem to me to be contrary to
a general attitude of the whole distribution. :-)

Comment 3 Glen Foster 2001-07-13 22:18:22 UTC
This defect considered SHOULD-FIX for Fairfax gold-release.

Comment 4 Preston Brown 2001-08-13 20:02:57 UTC
Doesn't make sense to me.

[pbrown@dionysus SPECS]$ touch -c -d 19990101 /var/log/sa
[pbrown@dionysus SPECS]$ ls -la /var/log/sa
total 8
drwxr-xr-x    2 root     root         4096 Jan  1  1999 .
drwxr-xr-x    4 root     root         4096 Aug 13 16:00 ..
find /var/log/sa \( -name 'sar??' -o -name 'sa??' \) -mtime +7
[ no output ]

Because the wildcards ?? are not getting matched.

? is defined as "matching any single character."  I.e. sa?? cannot match sa.

Are you sure you have properly defined the problem?

Comment 5 Michal Jaegermann 2001-08-13 22:08:49 UTC
Use whatever pattern which will match data files but it will NOT match
'sa' by itself.  If you prefer you can use '! -type d', if you want
to be on a safe side.  As data files have names which have at least
three characters long then you can use "-name 'sa?*'" and this will
not match /var/log/sa.  Data files happen have names 'sa' or 'sar'
followed by two digits.

Whatever.  The point is that we do not want to attempt to remove
/var/log/sa regardless how time-stamps happen to look at the given moment.
The underlying problem is that original assumes that /var/log/sa is
"new enough" to prevent that and this is not always the case.

This is not a very big issue until you will try 'rm -rf' but it generates
"garbage mail" to root in some circumstances.

Comment 6 Preston Brown 2001-08-24 14:25:24 UTC
Please read my comment, I still don't see how what you reported was possible.  
Not saying it didn't happen, but not understanding how it was possible. -name 
sa?? -o name 'sar??' should _never_ have matched a file/directory named just 

Comment 7 Michal Jaegermann 2001-08-30 23:17:02 UTC
> Please read my comment, I still don't see how what you reported was possible.

Sigh!  I thought that I was clear enough.  Let's try this way.  Drop time clause
from the original 'find' pattern and try yourself to see what this will match.
You will get /var/log/sa itself on this list as well. If for whatever reason
(I mentioned some possibilities) /var/log/sa has a time stamp which will
not eliminate it from a match with a full pattern then you will attempt
to remove it and here comes an error message.  In "normal" operations a time
stamp on /var/log/sa will be recent enough to prevent a match but not always
a situation is "normal".  Once again - this is not a big deal but any of
alternative cures is equally simple.

Comment 8 Preston Brown 2001-08-31 14:31:19 UTC
sorry, I was looking at the wrong regexp.

We do now have a better regexp for the 7.2 version (sysstat-4.0.1-2).

Note You need to log in before you can comment on or make changes to this bug.