06-06-2013 08:06 PM
The OS is HPUX 11.31 and many printers are running on this critical server. The lp log is very important log for the application team to monitor the printing status. Recently we implemented daily log rotation and scheduled in crontab.
The issue we having is everytime the copying process done at 9am everyday, the lp log size become small and only contains first 100 lines (the rest of the line went missing).
Herewith the crontab and script, pls help giving me some light here...
00 09 * * * /usr/local/bin/run-parts /etc/cron.daily >/dev/null 2>&1
for LOG_FILE_ROTATE in $LOGFILE
if [ -f $LOG_FILE_ROTATE -a -s $LOG_FILE_ROTATE ]
cp -p $LOG_FILE_ROTATE $COPY_FILE
cat /dev/null > $LOG_FILE_ROTATE
# ls -lrt
-rw-r--r-- 1 lp lp 261 May 12 09:00 log.Sun
-rw-r--r-- 1 lp lp 1038 Jun 1 09:03 log.Sat
-rw-r--r-- 1 root sys 43399 Jun 2 09:00 log.start
-rw-r--r-- 1 lp lp 7703 Jun 3 09:03 log.Mon
-rw-r--r-- 1 lp lp 3523 Jun 4 09:02 log.Tue
-rw-r--r-- 1 lp lp 5135 Jun 5 09:02 log.Wed
-rw-r--r-- 1 lp lp 3767 Jun 6 09:02 log.Thu
-rw-r--r-- 1 lp lp 3717 Jun 6 21:18 oldlog
-rw-r--r-- 1 lp lp 2343 Jun 7 09:03 log.Fri
-rw-r--r-- 1 lp lp 1029324 Jun 7 10:54 log <-- this log becoming log.$DAY on the next day but most of the lines will missing..
Thank you in advance..
06-06-2013 11:55 PM
Is there enough disk space for 2 copies of the /var/adm/lp/log to exist?
The script attepts to copy the current /var/adm/lp/log to /var/adm/lp/log.<day> before truncating /var/adm/lp/log.
If disk space is tight, it might be that it only can copy the first 100 lines or so before the disk becomes 100% full.
Because the script does not seem to have any error-checking at all, it won't notice this, and will truncate /var/adm/lp/log even if only part of it was successfully copied.
Note: if the system has been installed using HP-UX default LVM layout, then /var/adm/lp and /var/spool/lp are both using the space of the /var filesystem. If large print jobs are sent to the system at about 9am, they would be temporarily stored in /var/spool/lp before being sent to the printer, consuming the /var filesystem space. But after those print jobs are completed, the files in /var/spool/lp would be automatically deleted, giving the space back.
Please run "dmesg" and read the output. Does it include any messages about filesystems being full?
Also, please replace the ">/dev/null 2>&1" at the end of the cron job specification with something like ">/tmp/root-daily-cron.notices.txt 2>/tmp/root-daily-cron.errors.txt". Then let the job run once, and read at the /tmp/root-daily-cron.*.txt files. The messages in those files might make it easier to understand what the problem is.
06-07-2013 12:31 AM
>cat /dev/null > $LOG_FILE_ROTATE
No need for evil cat. Just use: > $LOG_FILE_ROTATE
>1029324 Jun 7 10:54 log <-- this log becoming log.$DAY on the next day but most of the lines will missing.
What's at the end of this large logfile? Something from Jun 7?
06-08-2013 12:25 PM
Disk space is not the root cause for this issue as there are plenty of free space and no disk full error in dmesg. But thank you for the good idea of replacing the ">/dev/null 2>&1" at the end of the cron job to the log file in the /tmp folder. Perhap I able to find something in this log file that maybe helpful in solving this issue..
06-08-2013 12:31 PM
Thank you for the reply. The active log file (log) is perfectly working fine as I can see it's updating the latest process at the end fo the file..but not in the copied log..hmmm..
root@gopgbl1: tail log
lkcfyp01-8811 indrajit lkcfyp01 Jun 9 03:19
Start: lkcfyp01-8811 Sun Jun 9 03:19:27 MAL 2013
End: lkcfyp01-8811 Sun Jun 9 03:19:27 MAL 2013
/opt/hpnpl/bin/hpnpf -j lkcfyp01-8811+indrajit -a1 -x 18.104.22.168
lkcfyp01-8812 indrajit lkcfyp01 Jun 9 03:19
Start: lkcfyp01-8812 Sun Jun 9 03:19:38 MAL 2013
End: lkcfyp01-8812 Sun Jun 9 03:19:39 MAL 2013
/opt/hpnpl/bin/hpnpf -j lkcfyp01-8812+indrajit -a1 -x 22.214.171.124