0

I have a simple bash script I'd like to run as a daemon...

#!/bin/bash
while true; do
crontab cron
sleep 58m
done

I run this as a daemon using this command...

setsid copy_cron.sh >/dev/null 2>&1 < /dev/null &

[1] 17025

But once it's running, I can't find a process for it in ps -aux..?

How do I make sure the daemon is running, or kill it if I need to?

ewwhite
  • 197,159
  • 92
  • 443
  • 809
some1
  • 79
  • 6
  • What is this script supposed to do and why don't you let `cron` handle something that is supposed to run about every hour? What you are doing there is not "running a daemon" ... – Sven Aug 06 '16 at 23:50
  • 1
    So you just want to make sure `crond` is running? – ewwhite Aug 07 '16 at 00:24
  • No, I'm installing a programmatically generated cron file into the crontab. – some1 Aug 08 '16 at 04:29
  • 1
    You can either do ps aux or ps -Af. Mark that one has a hyphen, the other doesn't. That hyphen changes the meaning of the options you have supplied to ps. If you try one of the ways specified above, you would be able to see the process. – euphoria83 Aug 20 '16 at 04:08

3 Answers3

1

First, your script doesn't specify an absolute path for the cron file, so it depends on being started in the correct directory.

Second, doing it in an independent free-running loop instead of chaining it to the process generating the file is prone to races.

Third, the user crontab is overwritten every time, causing any entries that might have been added by someone or something else than your script to be lost.

No fatal flaws, but violations of the principle of least astonishment that in my experience tend to bite you when the system is put into production.

Tilman Schmidt
  • 4,101
  • 12
  • 27
  • Fair enough, thanks for answering. Yes the script in the in same folder as the file. I don't understand point #2. #3 No one else uses the server. How would you update cron in a programmatic way if not by something like this? – some1 Aug 10 '16 at 00:55
  • ad 1.: Having the script in the same directory as the file is not enough. The directory must actually be the current working directory when you start the script. – Tilman Schmidt Aug 10 '16 at 23:10
  • ad 2.: Just run the "crontab cron" command from the process writing the cron file or from a wrapper script. That way it will always be reliably executed after the file has been written. – Tilman Schmidt Aug 10 '16 at 23:14
  • 1
    ad 3.: If the user id all this is running under is not used by anyone nor anything else - ie. if it is a dedicated user id used only for this single service - then there is no problem. – Tilman Schmidt Aug 10 '16 at 23:16
0

If your goal is to keep crond running, I'd suggest using Monit.

However, in most cases, there isn't a reason the cron daemon would stop running... so this may not be necessary.

For reference, I DO have this type of protection for my systems, and I use a Monit config that looks like:

check process cron
    with pidfile "/var/run/crond.pid"
    start program = "/sbin/service crond start"
    stop program = "/sbin/service crond stop"

If your goal is to run something on a schedule, just use cron.

ewwhite
  • 197,159
  • 92
  • 443
  • 809
  • 1
    The purpose of command "crontab cron" is not to make sure crond is running, but to install the file "cron" as the current user's crontab. (Yes, there are many problems with that approach.) – Tilman Schmidt Aug 07 '16 at 13:00
  • Oh, couldn't make sense of what was happening there. – ewwhite Aug 07 '16 at 13:01
  • @Tilman, the "cron" file is generated programmatically -- what are the many problems with this approach? – some1 Aug 08 '16 at 04:29
0

Simply do this

~$ nohup copy_cron.sh &

With ps awx it will appear to be running as

7168 pts/2    R      0:04 /bin/bash ./copy_cron.sh

Kill it like this

~$ kill 7168
Ryan Babchishin
  • 6,260
  • 2
  • 17
  • 37