FRAZIER%AFGLSC.SPAN@STAR.STANFORD.EDU (S. W. FRAZIER) (01/05/88)
I have an AT&T 3B1 running SYSV rel 3.5. I've recently noticed that cron is not being spawned when the system starts up. I am the only user on the machine and I know for a fact that it was being spawn earlier in 1987. (Cronlog in /usr/adm exists..) The only thing I remember doing was deleting the old /usr/adm/cronlog and copying /dev/null to /usr/adm/cronlog to start a new file. In any event Cron is not being spawned and I'd like to know how I can get it to start in the system boot procedures. I figure it's probably in either /etc/inittab or in /etc/rc but I'd like to avoid messing with it. Do I actually HAVE to have cron running? What are the consequences if I just ignore this little problem. Anyone out there proffer any advice??
john@wa3wbu.UUCP (John Gayman) (01/05/88)
In article <11098@brl-adm.ARPA>, FRAZIER%AFGLSC.SPAN@STAR.STANFORD.EDU (S. W. FRAZIER) writes: > > noticed that cron is not being spawned when the system starts up. > Do I actually HAVE to have cron running? What are the consequences Usually cron is fired up in /etc/rc along with possibly your LP scheduler, errdemon and several other things which can be started at boot time. The only purpose of cron is to make certain types of operations either automatic or time dependant. Ive seen some systems that do not use cron at all. If you prefer to do the housekeeping manually, then you do not need cron. And if all else fails, just re-start cron manually from root. At different times here, if I make a change in the cron time-table, I don not re-boot the whole machine. I simply kill the current cron job process and start it again from the console. The time/jobs are read in at execution time. Hope this helps. John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: wa3wbu!john@uunet.UU.NET Marysville, PA 17053 | Packet: WA3WBU @ AK3P
farren@gethen.UUCP (Michael J. Farren) (01/06/88)
In article <11098@brl-adm.ARPA> FRAZIER%AFGLSC.SPAN@STAR.STANFORD.EDU (S. W. FRAZIER) writes: > > I have an AT&T 3B1 running SYSV rel 3.5. I've recently >noticed that cron is not being spawned when the system starts up. The 3b1 spawns smgr (status manager), a replacement for cron which also handles the updating of the status line at the top of the console screen. You don't need cron, as smgr handles all of cron's tasks, as well as its own. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
brad@bradley.UUCP (01/07/88)
The status manager does the cron stuff (smgr). If you run cron
you problable should turn off smgr.
Bradley Smith UUCP: {cepu,ihnp4,noao,uiucdcs}!bradley!brad
Text Processing ARPA: cepu!bradley!brad@seas.ucla.edu
Bradley University PH: (309) 677-2337
Peoria, IL 61625dave@lsuc.uucp (David Sherman) (01/18/88)
In article <449@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes: > At different times here, >if I make a change in the cron time-table, I do not re-boot the whole >machine. I simply kill the current cron job process and start it again >from the console. The time/jobs are read in at execution time. Every cron that I have ever seen or heard of either rereads crontab every minute or so (v6 may have done this) or checks its modification time and rereads it when it changes. I would consider a cron that has to be killed off and restarted when you change crontab to be seriously brain-damaged. Perhaps you should check whether your supposition is really correct. David Sherman The Law Society of Upper Canada -- { uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!dave
dean@coplex.UUCP (Dean Brooks) (01/20/88)
In article <1988Jan17.235014.19530@lsuc.uucp> dave@lsuc.UUCP (David Sherman) writes: >In article <449@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes: >> At different times here, >>if I make a change in the cron time-table, I do not re-boot the whole >>machine. I simply kill the current cron job process and start it again >>from the console. The time/jobs are read in at execution time. > >Every cron that I have ever seen or heard of either rereads crontab >every minute or so (v6 may have done this) or checks its modification >time and rereads it when it changes. I would consider a cron that >has to be killed off and restarted when you change crontab to be >seriously brain-damaged. Perhaps you should check whether your >supposition is really correct. Actually, it is truth (perhaps not a desirable one) that cron, on some machines, checks the crontab entries only on two occasions. Once when CRON is first executed (or rebooted), and when a user executes the crontab command. From this, cron does NOT need to spawn every minute to check to see if anything needs to be run; rather, when it DOES execute something, it checks to see when it needs to wake up again. It can then remain dormant until it is needed again. (As opposed to eating up CPU time every minute of the day). This is true on our machine (PLEXUS P/75 UNIX 5.2(1.7)) and I am sure quite a few others... Hope to be of some help... {mit-eddie}!bloom-beacon!coplex!dean
mwm@eris (Mike (My watch has windows) Meyer) (01/20/88)
In article <1988Jan17.235014.19530@lsuc.uucp> dave@lsuc.UUCP (David Sherman) 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
[*] I haven't actually used this, just read the docs. I think it was
possible to have a single crontab ala v7/bsd/others.
--
Take a magic carpet to the olden days Mike Meyer
To a mythical land where everybody lays mwm@berkeley.edu
Around in the clouds in a happy daze ucbvax!mwm
In Kizmiaz ... Kizmiaz mwm@ucbjade.BITNETbrad@bradley.UUCP (01/20/88)
We have a 3b5 here (actually more than 1), that when a change is
made /usr/spool/cron/crontabs /etc/cron doesn't pick up the change
and the only way was to kill cron and restart it. I suppose I could
fix it but th eproblem is minor to other things
Bradley Smith UUCP: {cepu,ihnp4,noao,uiucdcs}!bradley!brad
Text Processing ARPA: cepu!bradley!brad@seas.ucla.edu
Bradley University PH: (309) 677-2337
Peoria, IL 61625jfh@killer.UUCP (John Haugh) (01/21/88)
In article <1988Jan17.235014.19530@lsuc.uucp>, dave@lsuc.uucp (David Sherman) writes: > In article <449@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes: > > At different times here, > >if I make a change in the cron time-table, I do not re-boot the whole > >machine. I simply kill the current cron job process and start it again > >from the console. The time/jobs are read in at execution time. > > Every cron that I have ever seen or heard of either rereads crontab > every minute or so (v6 may have done this) or checks its modification > time and rereads it when it changes. I would consider a cron that > has to be killed off and restarted when you change crontab to be > seriously brain-damaged. Perhaps you should check whether your > supposition is really correct. > > David Sherman In the OLD cron's, the crontab was read in at invocation time, and checked every minute to see if it changed. Looking at /usr/adm/cronlog (or whatever yours is named) would tell you when the crontab was read. The NEW cron's have individual crontabs for each (potential) user. Editing one of those files will not update cron's idea of what is going on. You must use the crontab command (with -l option) to get a copy of the crontab (or you can just copy it from /usr/spool/cron/crontabs/<what-ever>) and then put it back using the crontab command again. Does that answer the question completely? I suggest you drag out the manuals and see what other commands the cron entry refers you to and give all of them a read. - John. -- John F. Haugh II SNAIL: HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well? ... Dallas, TX. 75243 ... Then Buy One!" (214) 231-0993 Ext 260
lex@mustang.UUCP (Lex Mierop) (01/21/88)
In article <1988Jan17.235014.19530@lsuc.uucp> dave@lsuc.UUCP (David Sherman) writes: >In article <449@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes: >> At different times here, >>if I make a change in the cron time-table, I do not re-boot the whole >>machine. I simply kill the current cron job process and start it again >>from the console. The time/jobs are read in at execution time. > > Perhaps you should check whether your >supposition is really correct. I am using SunOS3.4/BSD4.3 and in this system, cron sleeps between events in the crontab file. If you change the crontab file, all you have to do is send signal #1 to cron and cron will wakeup and read the crontab file to determine how long to sleep until the next event. You can do this by typing the following: kill -1 %d where %d is the process id of cron. -- Lex Mierop | "Bandits, 11 o'clock low" {psivax,trwind,..}!nrcvax!mustang!lex |
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (01/22/88)
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)
maxwell@ablnc.ATT.COM (Robert Maxwell) (01/23/88)
In article <6621@agate.BERKELEY.EDU>, mwm@eris (Mike (My watch has windows) Meyer) writes: > In article <1988Jan17.235014.19530@lsuc.uucp> dave@lsuc.UUCP (David Sherman) 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[*]. In System V, crontab(1) is a command that makes, lists or removes a users crontab file. The use of the command to copy a file (or standard input) to /usr/lib/cron/crontabs directory signals cron to reexamine the crontab files to update it's schedule of cron jobs. (Read the man page for a detailed description) The system administrator can restrict access to the crontab(1) and at(1) commands. The default on all distributions I have worked with only allow root, sys, adm or similar administrative logins access to the commands and the administrator has to change it to allow others to use it. -- ----------------------------------------------------------------------------- Bob Maxwell AT&T DP&CT | All standard (and most non_standard) Maitland, FL ihnp4!ablnc!maxwell | disclaimers apply. -----------------------------------------------------------------------------
maxwell@ablnc.ATT.COM (Robert Maxwell) (01/23/88)
In article <435@ablnc.ATT.COM>, maxwell@ablnc.ATT.COM (Robert Maxwell) writes: > In System V, crontab(1) is a command that makes, lists or removes a users > crontab file. The use of the command to copy a file (or standard input) > to /usr/lib/cron/crontabs directory signals cron to reexamine the crontab ^^^^^^^^^^^^^^^^^^^^^^ My brain was out to lunch (it was Noon) :-) The directory is /usr/spool/cron/ crontabs. ^^^^^ Sorry 'bout that. -- ----------------------------------------------------------------------------- Bob Maxwell AT&T DP&CT | All standard (and most non_standard) Maitland, FL ihnp4!ablnc!maxwell | disclaimers apply. -----------------------------------------------------------------------------
ccea3@rivm.UUCP (Adri Verhoef) (01/23/88)
In article <3000@killer.UUCP> jfh@killer.UUCP (John Haugh) writes: >The NEW cron's have individual crontabs for each (potential) user. Editing >one of those files will not update cron's idea of what is going on. You >must use the crontab command (with -l option) to get a copy of the crontab To notify cron that there is a new crontab file U don't need a temporary file: crontab -l | <script> | crontab where <script> will usually be a sed(1) script.
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (01/24/88)
In article <5049@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >One thing I would like cron to do is run from /etc/inittab. Yes! Not only cron, but also the line printer scheduler and the error daemon! And, as he further points out, the modification is trivial for all of them -- just change: if (fork()) exit(0); to if (getppid() != 1) if (fork()) exit(0); Is that too easy, or what? I've made this change to cron, lpsched, and errdemon on every machine I've run, and it helps a \lot/ in controlling the machine usage. It makes it very easy to do things like stopping and starting daemons when going in and out of "single-user" mode (which is what I use init level one for) or when shutting down the system (ditto init level zero). I've even sent in the idea to both Pyramid and AT&T; so far, they have yet to act on it. Perhaps if more people requested the change? -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
jec@nesac2.UUCP (John Carter ATLN SADM) (01/29/88)
In article <10800014@bradley>, brad@bradley.UUCP writes: > > We have a 3b5 here (actually more than 1), that when a change is > made /usr/spool/cron/crontabs /etc/cron doesn't pick up the change > and the only way was to kill cron and restart it. Was I the only recipient of the information that you can get cron to accept new data in a particular crontab file by: 1) cd /usr/spool/cron/crontabs 1a) cp root root.bk (skip this if you never make mistakes :-) 2) ed root 3) make changes, write, quit 4) crontab root 5) cd back_to_where_you_started -- USnail: John Carter, AT&T, Atlanta RWC, 3001 Cobb Parkway, Atlanta GA 30339 Video: ...ihnp4!cuea2!ltuxa!ll1!nesac2!jec Voice: 404+951-4642 (The above views are my very own. How dare you question them? :-)
andrew@uel.uel.co.uk (Andrew Josey) (01/29/88)
In article <10800014@bradley>, brad@bradley.UUCP writes: > > We have a 3b5 here (actually more than 1), that when a change is > made /usr/spool/cron/crontabs /etc/cron doesn't pick up the change > and the only way was to kill cron and restart it. As of System V Release 2 and later, the crontab(1) command must be ran to force cron to examine the appropriate file. This reduces the overheads in checking for new or changed files at regular intervals. See cron(1M). -- Andrew Josey, AT&T Unix Europe, a Division of AT&T (UK) Ltd. International House, Ealing Broadway, London W5 5DB, England, UK uucp:{ mcvax!ukc, attunix} uel!andrew { The usual disclaimer .... }
wescott@sauron.Columbia.NCR.COM (Mike Wescott) (01/31/88)
> Was I the only recipient of the information that you can get cron to > accept new data in a particular crontab file by: > 1) cd /usr/spool/cron/crontabs > 1a) cp root root.bk (skip this if you never make mistakes :-) > 2) ed root > 3) make changes, write, quit > 4) crontab root > 5) cd back_to_where_you_started No. Don't do that. Use the "crontab -l" to get a copy to edit: 1) crontab -l > Crontab 2) ed Crontab 3) make changes, write, quit 4) crontab Crontab Much safer. Works for anybody that has permission to use cron. You don't need to be superabuser to use. Crontabs are usually -r--r--r-- and owned by root. -- -Mike Wescott wescott@ncrcae.Columbia.NCR.COM
maxwell@ablnc.ATT.COM (Robert Maxwell) (02/01/88)
In article <1012@sauron.Columbia.NCR.COM>, wescott@sauron.Columbia.NCR.COM (Mike Wescott) writes: > > No. Don't do that. Use the "crontab -l" to get a copy > to edit: ... > > Much safer. Works for anybody that has permission to use cron. > You don't need to be superabuser to use. Crontabs are usually > -r--r--r-- and owned by root. > -- If you are paranoid and use a 077 umask setting, your own crontab file will be -r-------- and owned by root. The crontab -l is the only way you can even read your crontab file. I think it has been mentioned, but using the crontab command to insert the new crontab file causes cron to scan the file and reschedule the jobs. -- ----------------------------------------------------------------------------- Bob Maxwell AT&T DP&CT | All standard (and most non_standard) Maitland, FL ihnp4!ablnc!maxwell | disclaimers apply. -----------------------------------------------------------------------------
jum@cosmo.UUCP (Uwe Mager) (02/23/88)
I have found it convenient to keep all crontabs in a directory (say /usr/adm/crontabs) and have make worry about updates: ------------------/usr/adm/crontabs/Makefile------------------------ DEST=/usr/spool/cron/crontabs CTABS=$(DEST)/adm $(DEST)/comm $(DEST)/news $(DEST)/root \ $(DEST)/sys $(DEST)/uucp .IGNORE: .PRECIOUS: $(CTABS) all: $(CTABS) $(CTABS): $$(@F) /bin/su $? -c crontab <$? -------------------------------------------------------------------- The .IGNORE is needed for the funny return codes delivered by crontab (at least on our machines). -- Jens-Uwe Mager jum@focus.UUCP || jum@cosmo.UUCP
njh@root.co.uk (Nigel Horne) (02/24/88)
In article <10800014@bradley> brad@bradley.UUCP writes: >We have a 3b5 here (actually more than 1), that when a change is >made /usr/spool/cron/crontabs /etc/cron doesn't pick up the change >and the only way was to kill cron and restart it. Actually there's no need to do that. You should change your crontab file using the crontab(1) command rather than by hand. This command will also "tell" cron that your file has been ammended and that it should reread. -Nigel -- -- Nigel Horne, Director of Quality and Programmes, UniSoft Ltd. <njh@root.co.uk> G1ITH Fax: (01) 726 2750 Phone: +44 1 606 7799 Telex: 885995 UNISFT G BT Gold: CQQ173
ghe@nucthy.physics.orst.edu (Guangliang He) (12/05/89)
I thought I understand how cron work until a minute ago. My SYS V
machine died last night and I booted it up this morning. After I loged
on, I found the time is still on last night. So I set the date.
Everything is ok. A while ago, I got a mail from cron report the daily
backup was completed. This surprised me. I thought the backup would be
skipped bacause it should be done in midnight and the machine was down
then. What happened to the cron? Do 'cron' and 'date' use different
clocks?
Any hints are welcome. Thanks in advance.
=======================================================================
USMAIL: Guangliang He | INTERNET: ghe@PHYSICS.ORST.EDU
Department of Physics | BITNET: hegl@ORSTVM.BITNET
Weniger Hall 301 |
Oregon State University |
Corvallis, OR 97331-6507 | PHONE: (503) 737-4631
=======================================================================paul@prcrs.UUCP (Paul Hite) (12/06/89)
In article <14202@orstcs.CS.ORST.EDU>, ghe@nucthy.physics.orst.edu (Guangliang He) writes: > > I thought I understand how cron work until a minute ago. My SYS V > machine died last night and I booted it up this morning. After I loged > on, I found the time is still on last night. So I set the date. > Everything is ok. A while ago, I got a mail from cron report the daily > backup was completed. This surprised me. If cron is running when you change the date it tries to compensate. If you set the clock back, cron waits for awhile so that it won't run something twice. And if you set the clock ahead (as I believe that you did), cron runs continuously until it catches up. This behavior of cron is useful if you're just tweaking the clock. But if you make a major change to the system time you probably should kill cron first, set the time, and restart cron. This way cron won't notice a clock change, so it won't try to compensate. Paul Hite PRC Realty Systems McLean,Va uunet!prcrs!paul (703) 556-2243 DOS is a four letter word!
root@grumbly.UUCP (Superuser) (03/10/90)
My machine is not run all the time. Does cron 'miss doing' the jobs scheduled will it is off or does it 'look back' and do the jobs scheduled during the time between the last shutdown and startup? Also, I have a copy of Xenix/386 2.3.2 for sale @ 50% list price. I also have SCO's version of X11 for it also at 1/2 price. Call Richard (408) 475-6539