recovering a broken pipe

[bobbybobbertson]

I have a perl script that is called like the following:

tail -f access.log | myperlscript.cgi

Every morning at some random time (usually around 4am) my server does something to the access.log. I think it copies the log to another name, zips it up, and then creates a brand new access.log.

After whatever happens, my script keeps running, but the new info that is being piped to access.log does not make it to my script. Is there anyway to force a recovery of the info being piped to the new file without restarting the script or tail function?

Is there a better way to call the tail function, to handle this problem?

 

[marsd]

Kill the cron/server process that runs the logrotation or have the perl script check
logfile size periodically and if the file size has drastically changed; restart the whole shebang.

 

[bobbybobbertson]

I can't find the server process that does this. I've checked cron for every user on the system, and no user is running any cron jobs (except the ones i have made).

I'm running a cobalt Raq4 server that runs RedHat Linux. Does Red Hat do this normally? Or is this a program that cobalt probably put on?

Where else should I look for a log rotation application?

 

[marsd]

Well, not knowing the answers about RH and/or cobalt , my
solution would be to amend the perl script.

However, in SuSE and some other flavors jobs like this can be kept in the /etc/cron.daily directory and run under "*rotate_log" type names. You could check there before recoding-or check with RH/cobalt to see where their scripts
are running from.

 

[GoldenEternity]

Try in the /etc/cron.* directories. Its called 'logrotate'.

 

[bobbybobbertson]

ok,
so i have a cron.daily directory and in it is a 'logrotate' shell script.

how does the cron.daily work? does anyting in this folder get executed daily or is this just a directory which holds scripts for a crontab.

i.e. to cleanly remove this script should i just delete it (actually rename and move it) or to i have to edit a crontab?

 

[marsd]

Remove the entry from /etc/crontab and/or rename the script:
the first takes care of all problems, the second takes care of the problem but generates errors.

 

[ifincham]

Hi,

On Redhat the default /etc/crontab looks something like :

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
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

What it means in practice is that 'run-parts' is triggered as per cron config time/date and it uses the directory argument to run all the scripts in that particular directory, e.g. /etc/cron.daily . The drawback is that you cannot vary the time of them individually.

You could certainly remove a script from /etc/cron.daily to prevent it running. However that wouldn't solve your original problem. Presumably -f causes tail to hang on to the original file descriptor regardless. I can only think of two possibilities at the moment - either change the logrotate script such that it kills your script before it does the rotate and then re-starts it at the end, or alter your script to use -n instead of -f and code your own loop which would recognise when the file changed. I would have thought that there would be much more overhead in the latter, however.

Hope this helps