Xref: utzoo comp.mail.uucp:3079 comp.unix.questions:13240
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!ncc!atha!lyndon
From: lyndon@cs.AthabascaU.CA (Lyndon Nerenberg)
Newsgroups: comp.mail.uucp,comp.unix.questions
Subject: Forcing SVR3 cron to re-read crontabs
Summary: sorry ...
Keywords: root uucp crontab su
Message-ID: <558@aurora.AthabascaU.CA>
Date: 4 May 89 01:29:17 GMT
References: <75@norsat.UUCP> <2008@egvideo.UUCP> <1524@auspex.auspex.com> <483@sequoia.UUCP>
Reply-To: lyndon@nexus.ca
Followup-To: comp.unix.questions
Distribution: na
Organization: Athabasca University
Lines: 25

[ This has nothing to do with mail anymore - followups in comp.unix.questions ]

In article <483@sequoia.UUCP> dewey@sequoia.UUCP (Dewey Henize) writes:
>In article <1524@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>The S5R3 "cron" and, I think, the S5R2 "cron", do not check any of the
>>"crontab" files unless they're told to;
>
>Can someone who's looking at source or speaking from experience tell me, please,
>HOW they're told to?  Is there a signal that could be used?  It would seem the
>most 'unixy' thing, but I've not found it in any of our docs, and we don't have
>any source...

The SVR3 cron communicates with the crontab command via a named pipe
(/usr/lib/cron/FIFO) that's created when cron starts up. You would
have to fake the messages being written on the pipe to get cron to do
its internal updates, which means re-inventing crontab(1), so why bother?

Unfortunately, cron no longer pays attention to signals (other than
SIGTERM) so kill -1 no longer does anything. You could write a script
to pull cron's PID out of a ps listing, send it a SIGTERM, then restart
cron. Or you could just use crontab(1) ... :-)

-- 
Lyndon Nerenberg   Computing Services   Athabasca University
{alberta,attvcr,ncc}!atha!lyndon  ||  lyndon@nexus.ca