Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrcae!sauron!wescott
From: wescott@Columbia.NCR.COM (Mike Wescott)
Newsgroups: comp.sys.ncr
Subject: Re: cronlogs on 600 & 650
Keywords: cron logs 600 650
Message-ID: <2026@sauron.Columbia.NCR.COM>
Date: 2 Mar 90 16:05:36 GMT
References: <366@cmsfl>
Sender: news@sauron.Columbia.NCR.COM
Reply-To: wescott@micky.Columbia.NCR.COM (Mike Wescott)
Organization: E&M-Columbia, NCR Corp, W Columbia, SC
Lines: 30

In article <366@cmsfl> nigel@cmsfl@labtam.oz (Nigel Harwood) writes:
> The Tower 32/650 under 2.01.01 has a nice feature where cron automatically
> limits its /usr/lib/cron/log to a reasonable size.

It's not really that nice since it insists on writing to the console and
cron will hang if it can't get to the console, or if the console is in
flow control.

> Any suggestions on the best way to do this ?
> It sounded trivial to me initially until I found that cron keeps its
> log open.  This means that if I do anything like copying the last
> 1000 lines to a new file and then moving the new file over the old,
> cron will still have the handle to the old file.  As well as the problem
> of the data cron is writing in the mean time.

> Sounds to me like I need to stop cron and then deal with the log, restarting
> it when I have finished.

Your best bet is to periodically (via cron) run a script that checks the size
of the log.  Run this script at otherwise quiet times for cron (to avoid lost
log entries).  If the log is big enough, then copy it to olog and then truncate
the log.  Cron keeps the log file open but only appends so truncating will 
work as expected.

This is the way it works in later SysV releases.


--
	-Mike Wescott
	 mike.wescott@ncrcae.Columbia.NCR.COM