GZIP syslog.log

[clefeitosa]

Hello folks!

I'm using HPUX 11

Please I would like to know what happen with my syslog.log because I have some servers that is on the same situation in the same time.

There is something that is running in my Servers that is gziping my syslog and I don't know what... below:

/var/adm/syslog> ll
total 400
-r--r--r-- 1 root root 115447 Apr 10 06:02 mail.log
-rw------- 1 root root 24047 Mar 30 09:09 sudo.log
-rw-r--r-- 1 root root 72 Apr 10 17:07 syslog.log
-rw-r--r-- 1 root sys 1411 Apr 10 17:07 syslog.log.1.gz
-rw-r--r-- 1 root sys 3964 Apr 3 17:07 syslog.log.2.gz
-rw-r--r-- 1 root root 1314 Mar 6 18:08 syslog.log.3.gz
-rw-r--r-- 1 root root 3796 Feb 27 18:07 syslog.log.4.gz
-rw-r--r-- 1 root sys 1204 Feb 20 19:07 syslog.log.5.gz

Please, could someone saw something like that and give me a help?

Thanks a lot!
clefeitosa

[Sundar_7 · Accepted solution]

All I could think of is a cron.

# crontab -l

Review the scripts. You might get a clue.

[Court Campbell]

either someone wrote a script to rotate the logs, or you have logrotate installed.

[Bill Hassell]

There is nothing in HP-UX that will do this. A root user has installed a script or program that is reducing very large logfiles by copying the old log, then uses gzip to reduce the size (significantly). This is very likely an entry in root's crontab since the date on each gzip'ed file is within 1 minute (19:07 18:07 17:07) and always on a Tuesday. The hourly difference may be explained if your root administrator has been changing the time on your system (not recommended).

Now these gzip'ed files are read just as easily as the standard syslog.log. Use the zcat command as in:

zcat syslog.log.3.gz | grep -e fail -e warn -e err

Note that the files are quite small so you can change the crontab entry to once a month rather than once a week.

[Bill Hassell]

There is nothing in HP-UX that will do this. A root user has installed a script or program that is reducing very large logfiles by copying the old log, then uses gzip to reduce the size (significantly). This is very likely an entry in root's crontab since the date on each gzip'ed file is within 1 minute (19:07 18:07 17:07) and always on a Tuesday. The hourly difference may be explained if your root administrator has been changing the time on your system (not recommended).
javascript:postAnswerSubmit('submit');
Submit
Now these gzip'ed files are read just as easily as the standard syslog.log. Use the zcat command as in:

zcat syslog.log.3.gz | grep -e fail -e warn -e err

Note that the files are quite small so you can change the crontab entry to once a month rather than once a week.

[clefeitosa]

Hi!

Unhappyly I don't have anything in my crontab...

[Bill Hassell]

Check the atjobs directory in /var/spool/cron/atjobs. Also look for recent files in root's $HOME, /usr/local and /usr/contrib. Use find to locate things that were modified in the last 60 days:

(logged in as root)
find $HOME /usr/local /usr/contrib -type f -perm -111 -exec ll {} +

The script or program doing this will probably show up with a name containing the words log or zip or rotate.

[Court Campbell]

see if you have this directory

/opt/logrotate

or try

swlist | grep -i logrotate

logrotate is a program that has this same behavior.

[clefeitosa]

Guys,

#:>/var/spool/cron/atjobs> ll
total 0

I dont have the directory /opt/logrotate and nothing with swlist | grep -i logrotate

When I tried the command:
find $HOME /usr/local /usr/contrib -type f -perm -111 -exec ll {} +

... i didn't have success.

I'm studying...

thanks!

[Bob E Campbell]

Bill is absolutely right in that these timestamps are a smoking gun (does the 2nd hourly shift match the new DST change?)

If you cannot find an atjob or crontab for any UID=0 user on this system, that might mean that the crontab is elsewhere. If you really find nothing locally, run:

# last -R

and then look for weekly root logins that match that timestamp.