16

I'm looking for a standard way or best practice to keep a daemon started by an init.d shell script alive.

Or even better, is there a way to keep it alive directly from /etc/init.d?

Specifically, I have a daemon called dtnd with and infinite loop that looks for unexpected ended process, if there are any, the daemon wake up them again. Also, I use the start-stop-daemon tool in order to let the precess by run from a given system user.

I want to run this dtnd daemon from startup. In order to achieve this behavior I created a init.d script that "wraps" the dtnd file using start, stop and status commands.

I have 2 questions that I will like to solve:

  1. Is there a way to achieve keeping alive some process from init.d shell script. Is an standard/best way practice?

  2. It's recommended to keep a process alive with infinite loop? I guess it's better to use some command like respawn to achieve that. It's correct?

I know about the existance of the respawn command. I think that's what I need but I don't understand the workflow between /etc/init.d/ and /etc/init. Can anyone help me?

Note that I don't have inittab neither upstart (I'm only allowed to use /etc/init, /etc/init.d, cron and system tools as start-stop-daemon. I mean, only the default tools)

Thank you so much for your time!

Adrian Antunez
  • 473
  • 1
  • 5
  • 10
  • possible duplicate of [Shell script to execute something when one of the daemon dies?](http://serverfault.com/questions/16243/shell-script-to-execute-something-when-one-of-the-daemon-dies) – ewwhite Jul 10 '14 at 13:36

5 Answers5

15

Debian will eventually have systemd, so this is the way to do it on a Linux system which uses systemd (and many do already; you might consider switching distributions).

Systemd can handle keeping the service alive for you automatically; no other tools are required. Simply make sure that Restart=always is set in the service file's [Service] section.

# vi /etc/systemd/system/dtnd.service

[Service]
Restart=always
#...everything else...

Several other options are available as well, for more complex scenarios.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • 2
    While the future shows more flexible options, does this take care of the current environment/conditions? Installing a tool seems to be the path of least-resistance compared to a forklift distribution change/upgrade. – ewwhite Jul 11 '14 at 11:48
  • @ewwhite It depends. Debian has systemd since wheezy, but it wasn't the default init. It should be the default from jessie. And since our user accepted the answer, I presume he was already using systemd for another reason (or had permission to install it). – Michael Hampton Jul 11 '14 at 12:59
  • `systemd` seems discard `init.d` script & base on `*.service` – yurenchen Feb 28 '18 at 19:26
  • 2
    Instead of directly editing use the safer `systemctl edit myservice`, then `systemctl daemon-reload` and restart myservice. – Pablo A May 12 '18 at 05:29
  • @PabloBianchi Creating an override is fine if you are overriding an existing service's unit. If you are creating a unit from scratch, as the OP did, then it's pointless. – Michael Hampton May 12 '18 at 07:36
4

You could add it to /etc/inittab with respawn:

d1:2345:respawn:/path/to/your/first_daemon arg1 arg2
d2:2345:respawn:/path/to/your/second_daemon arg1 arg2

It's a dirty hack, but I've used it succesfully in the past on older sysv-init systems.

Gajus
  • 831
  • 5
  • 15
  • 27
Dennis Kaarsemaker
  • 18,793
  • 2
  • 43
  • 69
  • But don't daemons uually cal setsid() and fork() to run in the background? – symcbean Jul 11 '14 at 07:45
  • Thank you! As you say it's a dirty hack but it works. Anyway I prefer the usage of systemd. Now I know about it existence. – Adrian Antunez Jul 11 '14 at 08:34
  • This doesn't work on RHEL6. The respawn utility doesn't seem to be available. – Djidiouf Sep 26 '16 at 05:01
  • The downside to this approach is the only way to intentionally stop the process is to comment out that line in /etc/initab, rehup the init process, and kill your process; then reverse to restart it. If you use a monitoring script, you can differentiate between the process dying and being intentionally shutdown. – pavon Mar 15 '21 at 15:34
2

Well, that is one of the main reason, why debian is moving to systemd.

sysvinit (/etc/init.d) is not able to detect, if a service is down/not responding. This means you have to monitor these services and escalate if a service won’t do his job anymore.

probably the easiest thing to do would be to migrate to another daemonhandler like systemd (default in RHEL7, will be default in next debian and ubuntu lts), upstart (default in RHEL6, Ubuntu 12.04 and 14.04), daemontools (like mentioned, develloped by djb) or something else.

doing the job of keeping a service alive will be PITA in sysvinit.

janaurka
  • 21
  • 1
1

Best practice is to ensure that your daemons DO NOT STOP in the first place.

Failing that you might want to have a look at DJB's daemontools

symcbean
  • 19,931
  • 1
  • 29
  • 49
  • 3
    Of course the best practice is to ensure that my daemons do not stop. But there is a lot of applications that follow the if-I-stop-wake-me approach like apache2, mysql, samba, pulseaudio... I've been looking for daemontools and seems a good approach. Unfortunately, I'm not allowed to install external tools. I need to do it using bash scripting or start-stop-daemon and init.d configs. – Adrian Antunez Jul 10 '14 at 12:24
1

The standard approach for me is to use the Monit utility for this.

I can't quite tell from your description if you've written something like Monit and are trying to make sure it's running, or if you need something to watch the daemon you've created.

ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • 1
    Hi ewwhite, I have to ensure that my application it's running. Unfortunately, I'm not allowed to install external tools. I need to do it using bash scripting or start-stop-daemon and init.d configs. – Adrian Antunez Jul 10 '14 at 12:22
  • 2
    @AdriánAntúnez If you are not allowed to install the tools you need to do your job, you should fix that problem as soon as possible. – Michael Hampton Jul 10 '14 at 12:44
  • @AdriánAntúnez You asked for "standard". Monit is pretty well-known/well-regarded. You asked for "best"... Your constraint is more of a political one. *Why* wouldn't you be allowed to install software? – ewwhite Jul 10 '14 at 13:13
  • I think there is a misunderstanding. I need to run and keep alive a set of daemons at startup (runlevel 2). Like /etc/init.d/apache2 will do. I need to achieve that behaviour using the standard Debian/Ubuntu tools in order to have good compatibility between systems as well as avoid unnecessary dependences of externals tools. – Adrian Antunez Jul 10 '14 at 13:20
  • 1
    It's not an unnecessary tool or dependency if it [does what you want it to do](http://serverfault.com/tags/monit/info). – ewwhite Jul 10 '14 at 13:24
  • 1
    @ewwhite Sorry, I meant avoid dependences of external tools. – Adrian Antunez Jul 11 '14 at 08:32