[svlug] Complicated logs rotation under cron and date format in Linux/Unix

[David E. Fox]

> That's a 3 seek hard disk torture when a few simple lines in crontab would
> do! It would be easier to manage and understand.

Agreed that it's some extra work. Logrotate could be implemented more
cleanly - just with a script that cp's the old log into another file,
like:

cp foo.log.1 foo.log.2
cp foo.log foo.log.1
cat /dev/null foo.log

etc. with compression as well. But RH, Mandrake, etc. have put in a 
logrotate with other stuff in there to centralize (at least it appears
so) various options with respect to configuration nnd so forth.

It's not all that difficult to follow the 'forest' of symlinks and 
stuff - but I'm not saying that's the right way to do things anyway :). But
complaining about a few extra seeks ? :)

 
> Who's idea was it to kill mysqld that way? If I remember correctly it's
> recommend to shutdown the database gently.

That may be, but it's standard (at least I think so, others may disagree,
I'm not a sysadmin) to kill -HUP. At least that's better than kill -9. And
killing the deamon during the rotate is standard as well - what happens if
the deamon is trying to write to the log file during the time you're trying
to rotate it?

 
> the program won't start for some reason, lock file was not removed, binary
> file read error, etc. Seen it happen.

Never happened yet :) but the daemon is supposed to write to the (new) lock
file anyway. 
 
> Second and perhaps more important is security. Let's say the system has
> been broken into with some kind of "string spillover". Simply looking into
> the ps table one can tell (almost always) by PID number that the daemon
> has been restarted and then investigate why that happened.

I'm not sure where you're going here. If you kill the deamon, you're going
to restart it, and you're going to get a new PID. What's wrong with that? If
you want someone to be able to investigate why you restarted a deamon, you
can't unless you get a new PID, right? Maybe kill -STOP is better? that way
you can stop the process, redo the logs, and then kill -CONT? And then you'd
still have the same PID.

 
> authenticate the users. The bad thing happens when the log rotates at 4:02
> (RH default, why 4 and not 0:03?) in the morning. That kills current

It's been suggested (at least in books like Unix Power Tools) to start
cron jobs at odd times - figuring you're on a multiuser machine, if everyone
starts jobs at 2:00 am, you got a machine that's bogged down trying to 
run everyone's scripts at once. Simply running the job at an odd time like
4:03 or 1:11 or what have yuo alleviates that problem, and there's no 
requirement that the script run at 2:00am exactly, anyway, as it makes
little difference if the results are dated 2:00 vs 2:11.


> Let's say that the date is part of a file name and you want to use the
> above format. What you get is myfile_08/11/01:15.28.log for example. A
> complete screw up.

Ouch! :( Someone doesn't know that '/' isn't a permissible character in
a Unix file name. unless of course you want all logs for the 11th to go
into a separate directory named 11 :).

> Why not simply using universal (Worldwide understandable date format)  
> sequence date +%Y-%m-%d_%H:%M that yields 2001-07-13_15:29? Simple, clean

Why even bother with soemthing that long? If you only generate logs once
per day, why bother differentiating seconds? For that matter, why have
timestamps in file names to begin with? The date recorded in the inode
should be sufficient.

> Comments welcome.
------------------------------------------------------------------------
David E. Fox                              Thanks for letting me
dfox at tsoft.com                            change magnetic patterns
dfox at m206-157.dsl.tsoft.com               on your hard disk.
-----------------------------------------------------------------------