topic GZIP syslog.log in Operating System - HP-UX

GZIP syslog.log

clefeitosa — Tue, 10 Apr 2007 15:29:40 GMT

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

Re: GZIP syslog.log

Sundar_7 — Tue, 10 Apr 2007 15:35:04 GMT

All I could think of is a cron.

# crontab -l

Review the scripts. You might get a clue.

Re: GZIP syslog.log

Court Campbell — Tue, 10 Apr 2007 15:38:04 GMT

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

Re: GZIP syslog.log

Bill Hassell — Tue, 10 Apr 2007 22:00:39 GMT

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.

Re: GZIP syslog.log

Bill Hassell — Tue, 10 Apr 2007 22:01:07 GMT

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&colon;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.

Re: GZIP syslog.log

clefeitosa — Wed, 11 Apr 2007 06:21:21 GMT

Hi!

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

Re: GZIP syslog.log

Bill Hassell — Wed, 11 Apr 2007 06:33:05 GMT

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.

Re: GZIP syslog.log

Court Campbell — Wed, 11 Apr 2007 06:47:12 GMT

see if you have this directory

/opt/logrotate

or try

swlist | grep -i logrotate

logrotate is a program that has this same behavior.

Re: GZIP syslog.log

clefeitosa — Thu, 12 Apr 2007 09:59:28 GMT

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!

Re: GZIP syslog.log

Bob E Campbell — Sat, 14 Apr 2007 01:24:03 GMT

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.