Path: utzoo!utgpu!water!watmath!clyde!cbosgd!osu-cis!tut!lvc
From: lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani)
Newsgroups: comp.unix.questions
Subject: Re: Cron
Summary: feature request
Message-ID: <5049@tut.cis.ohio-state.edu>
Date: 22 Jan 88 03:27:40 GMT
References: <11098@brl-adm.ARPA> <449@wa3wbu.UUCP> <6621@agate.BERKELEY.EDU>
Organization: Ohio State Computer & Info Science
Lines: 34

In article <6621@agate.BERKELEY.EDU>, mwm@eris
	(Mike (My watch has windows) Meyer) writes
> <Every cron that I have ever seen or heard of either rereads crontab
> <every minute or so
> 
> Crontab? SysV doesn't have a "crontab". It has a /usr/lib/cron, which
> is full of little crontab files[*]. Stat()ing them all once a minute
> could get quite expensive. As a result, it doesn't do that - you need
> to send it a signal to make it reread them all. That's why there's a
> command to read your crontab file, or replace it. That command takes
> care of sending the signal for you.
> 
> The cron I wrote for the GNU project behaves the same way.
> 
> 	<mike

One thing I would like cron to do is run from /etc/inittab.
Some applications rely on cron very heavily, without it, chaos
results.  Occasionally, cron will get killed, not a big deal
as long as it gets restarted.

Currently cron forks() and then the parent exits, I guess this
is needed so when you run cron out of /etc/rc you don't have to
write nohup /etc/cron & (which prints a process id).  I modified
my cron to check if the parent was init.  (running out of
/etc/inittab - this can be faked out).  If you use the standard
version of cron in /etc/inittab you eventually get your process
table full of crons!  Stupid program.

-- 
oo
Larry Cipriani, AT&T Networks Systems (by day) Ohio State University (by night)
Domain: lvc@tut.cis.ohio-state.edu
Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (yes its right)