Ron Halstead wrote:
pgrep -fl cron
508 /usr/sbin/cron
sudo kill 508 # or sudo pkill cron
As a general rule for SMF-controlled processes, the first command only
works if the service is configured to ignore signals (which cron is).
Specifically, kill will succeed in sending the signal,
*And* when the crontab/at commands are run.
Which restarts cron unless there were no changes
made, it which case crontab is not read
No, crontab signals cron through /etc/cron.d/FIFO, which then re-reads the
crontab. cron is not restarted. This is easily verifiable through truss, and
Cron only reads the crontab file when it starts. Man cron and search for
'examines'. As you found out, sending a HUP doesn't work. Since cron runs as a
SMF controlled service in Solaris 10, killing the process will cause SMF to
restart it. The crontab file will then be read and changes, if any,
On 16 Jan 2011, at 21:13, Ron Halstead wrote:
Cron only reads the crontab file when it starts. Man cron and search for
'examines'.
*And* when the crontab/at commands are run.
---
cron only examines crontab or at command files during its
own process initialization phase and
From: opensolaris-discuss-boun...@opensolaris.org [mailto:opensolaris-
discuss-boun...@opensolaris.org] On Behalf Of Forrest Aldrich
I ran into an unfortunate problem with cron recently, where I had
assumed
that a HUP signal would cause it to re-read a new crontab entry. The
result
was a
I ran into an unfortunate problem with cron recently, where I had assumed
that a HUP signal would cause it to re-read a new crontab entry. The result
was a script was run that deleted some data.
Turns out, the code shows SIGHUP, SIG_IGN. I was not happy.
In any case, I want to understand
On Fri, Jan 14, 2011 at 4:32 PM, Forrest Aldrich for...@gmail.com wrote:
Running crontab -e is not applicable to what I'm doing here. I experimented
with it and it turns out you can't use that functionality in a scripted
environment, it doesn't work. I have a script that edits a line of
