3

My script (located in /etc/init.d) is creating a pid file ($PIDFILE), but there is no process running. My daemon script includes:

start-stop-daemon --start --quiet --pidfile $PIDFILE -m -b --startas $DAEMON --test > /dev/null || return 1

The script works fine when executing it manually.

mjpsr11
  • 595
  • 3
  • 10
  • 25

2 Answers2

3

You need to create startup links.

sudo update-rc.d SCRIPT_NAME defaults

then reboot. SCRIPT_NAME is the name of the script in /etc/init.d (Without the path)

hek2mgl
  • 152,036
  • 28
  • 249
  • 266
  • All /etc/rc*.d/ folders and files are included and updated for the script. Result of this command is: System start/stop links for /etc/init.d/timekpr already exist. – mjpsr11 Nov 28 '13 at 22:00
  • I also `sudo update-rc.d -f SCRIPT_NAME remove` and `sudo update-rc.d SCRIPT_NAME defaults`. The script is able to produce a pid, but there is no process running for it. `ps pid` only returns an empty result. – mjpsr11 Nov 28 '13 at 22:26
  • Used `sysv-rc-conf --list SCRIPT_NAME` with result of 0:off 1:off 2:on 3:on 4:on 5:on 6:off and `runlevel` is N 2. – mjpsr11 Nov 28 '13 at 22:48
  • What type of Linux distribution are you running? – hek2mgl Nov 28 '13 at 23:01
  • Linux Mint is debian based so it should work. Unfortunately not having a Mint test system at the moment. – hek2mgl Nov 29 '13 at 08:38
  • Do I need a SCRIPT_NAME.conf file in my /etc/init folder? – mjpsr11 Nov 29 '13 at 13:45
  • No. Check this (Starting at 9.3) http://www.debian.org/doc/debian-policy/ch-opersys.html – hek2mgl Nov 29 '13 at 13:47
  • Mint (also based on Ubuntu) includes Upstart which is an alternative to SysVinit on Debian. I wonder if there is a conflict between Upstart and SysVinit that prevents my script from staying alive after boot. If not, SysVinit (using start-stop-daemon) first creates a pid (evident by the pid file), then kills it (evident by no process with that pid or daemon name). What is the best way to debug or log output of start-stop-daemon or the boot process? – mjpsr11 Nov 29 '13 at 15:59
  • You are right about that, `upstart|SysVinit` topic. Can't say much at the moment, will investigate this. Expected that upstart will gracefully work with init scripts.. (at least it does on older ubuntu versions) – hek2mgl Nov 29 '13 at 16:02
2

Was able to get it working, but tried so many things, don't know exactly what fixed it (probably an error in script or config). However, learned a lot and wanted to share since I can't find much of the same in the internet abyss.

It seems Ubuntu (and many other distros based on Ubuntu, including Mint) has migrated to Upstart for job and service management. Upstart includes SysVinit (using /etc/init.d daemons) compatibility that still can use update-rc.d to manage daemons (so if you are familiar with that usage, you can keep on using it). The Upstart method is to use a single .conf file in the /etc/init folder. My SCRIPT.conf file is very simple (I'm using a python script):

start on filesystem or runlevel [2345]
stop on runlevel [016]

exec python /usr/share/python-support/SCRIPT/SCRIPT.py

This simple file completely replaces the standard script in /etc/init.d with the case statement to provide [start|stop|restart|reload] functions and the pointer to /usr/bin/SCRIPT. You can see that it includes runlevel control that would normally be found in the /etc/rc*.d files (thus eliminating several files).

I tried update-rc.d to create the necessary /etc/rc*.d/ files for my daemon. My daemon bash script is located in /etc/init.d and includes the start-stop-daemon command as in my original question. (That command also works fine from terminal.)

I had /etc/rc*.d/ files, the bash script in /etc/init.d and /etc/init/SCRIPT.conf file during boot and it seems that Upstart likely first looks for the .conf file for its direction because the SysVinit command service SCRIPT [start|stop|restart|reload] returns Unknown Instance, however you can find the process is running with ps -elf | grep SCRIPT_FILE.

One interesting thing to note is the forking of your daemon when using .conf. The script as written above only spawns one fork of the daemon. However, total independence of the original script is possible by using expect fork or expect daemon and respawn (see the Upstart Cookbook for reference). Using these will ensure that your daemon will never be killed (at least by using the kill command).

I continued to test both my daemon and the boot process by utilizing the sudo initctl reload-configuration command. This reloads the conf files where you can test your daemon by the sudo [start|stop|restart] SCRIPT command. The result of the start command is:

$ sudo start SCRIPT
SCRIPT start/running, process xxxx

$ sudo restart SCRIPT
SCRIPT start/running, process xxxx

$ sudo stop SCRIPT
SCRIPT stop/waiting

Also, there is a nice log in /var/log/upstart/SCRIPT.log that gives you useful information for your daemon during boot. Mine still has a very annoying bug that prevents root from displaying osd messages with notify-send from my daemon. My log file includes a gtk warning (I will open another question to solicit help).

Hope this helps others in developing their daemons.

mjpsr11
  • 595
  • 3
  • 10
  • 25