4

I have been trying to set up a script to run at boot on a Debian 7.1 system for a while now with no luck. I've tried using both insserv and update-rc.d, but my issue seems to be the same with either tool. Here is the LSB portion of my script:

#!/bin/bash

### BEGIN INIT INFO
# Provides:             start_guest
# Required-Start:       $bootlogs $sudo $virtualbox-guest-utils $syslog
# Required-Stop:        $bootlogs $sudo $virtualbox-guest-utils $syslog
# Should-Start:
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    start_guest
### END INIT INFO

With update-rc.d, here are the various commands I have tried, all with the same result:

sudo update-rc.d start_guest defaults
sudo update-rc.d start_guest defaults 22
sudo update-rc.d start_guest start 22 2 3 4 5 . stop 78 2 3 4 5 .

No matter which one I run, I am told this (showing runlevel 2 only as 2,3,4,5 are the same and 0,1,6 are all K01):

insserv: remove service /etc/init.d/../rc2.d/S21rc.local
insserv: enable service ../init.d/rc.local -> /etc/init.d/../rc2.d/S20rc.local
insserv: remove service /etc/init.d/../rc2.d/S21rmnologin
insserv: enable service ../init.d/rmnologin -> /etc/init.d/../rc2.d/S20rmnologin
insserv: enable service ../init.d/start_guest -> /etc/init.d/../rc2.d/S17start_guest

I can't ever get it to start somewhere other than S17 no matter what kind of dependency information I get it. Unfortunately, ../rc2.d/S19bootlogs will be started after my script, which will prevent me from obtaining sometimes critical logging information.

When I attempt to do the same thing with insserv, I am told that normal services have been instructed to start my new service, but it still doesn't seem to be following dependency ordering. I need several more services to be running before start_guest starts running (things like sudo, virtualbox-guest-utils, etc.)

me@bronze:/etc/init.d# sudo insserv start_guest 
insserv: Service remote_fs has to be enabled to start service start_guest
insserv: Service syslog has to be enabled to start service start_guest
insserv: exiting now!

David Krmpotic's answer to this question almost answers mine, but it doesn't seem like even the "Required-Start" dependencies are being followed either.

How do I get my script to run at boot and follow the given dependencies? Thank you!

Community
  • 1
  • 1
MtWoRw
  • 196
  • 1
  • 1
  • 12

2 Answers2

9

As it turns out, there are three different ways to add dependencies into the LSB header and very little documentation to explain these differences. The correct LSB header for my purposes is actually this:

# Required-Start:       bootlogs sudo virtualbox-guest-utils $syslog
# Required-Stop:        bootlogs sudo virtualbox-guest-utils $syslog

(On both lines, I could have removed both sudo and virtualbox-guest-utils as it is bootlogs that forces my start_guest script to start the latest.)

Once my LSB header followed this syntax, I was able to run update-rc.d start_guest defaults and it did exactly what I wanted.

When listing services which need to start or stop before or after a new init script, there are a few ways to list them.

  • Use $name to refer to a facility service or a virtual service
  • Use name to refer to a single existing service <-- what I needed all along
  • Use +name to refer to a service which is optional

Some of this is mentioned in documentation, but it is not clear and broken up between various sections and even kinds of documentation. Every example I have come across only uses facility services, without including any normal or optional services, leading me to great syntax confusion.

From the man pages for insserv: 

insserv  scans  for  System Facilities in the configuration file /etc/insserv.conf
and each file in the directory /etc/insserv.conf.d/.  Each line which begins with
$ and a following name defines a system facility accordingly to the Linux Standard
Base Specification (LSB)

and:

Names starting  with a `+' sign are marked as optional.  If the service with the
name after the plus sign is available it will be used,  if  not  available  it
is  ignored silently.

I didn't intend to ask and then answer my own question. I've been puzzling over this issue for over a month and while I had been given hints, nothing gave me a full enough answer that I could see it doing what I needed it to do. Revisiting things weeks later gives me way better insight, even if there is still puzzling involved.

MtWoRw
  • 196
  • 1
  • 1
  • 12
  • 1
    Thanks for your question and answer, but I am still not able to add a dependency on `sudo`. `sudo` has a priority of 75, while my script that depends on `sudo` gets a priority of 20. – HRJ Aug 17 '14 at 13:24
  • 1
    From what I've seen, sudo having a priority of 75 is fairly low. The majority of my services had a priority of 25 or less, even the ones I added. What happens when you run a line like `sudo update-rc.d sudo defaults 18` (where 18 would be a reasonable number for when sudo should start on your system)? – MtWoRw Sep 04 '14 at 16:57
  • But then, that wouldn't prove anything. If the sudo priority is changed to 18, then my script having 20 would be a predictable outcome. The real proof of dependency resolution would be if original priorities are respected. – HRJ Sep 07 '14 at 14:30
0

To expand on MtWoRw's answer...

When adding dependencies into the LSB header, make sure the dependencies matches the identifier in the "Provides:" field of the dependency's init script, not the name of the dependency's script in /etc/init.d.

I ran into this trying to make mpd start after the avahi-daemon. In Raspbian, the avahi-daemon init script "Provides: avahi". insserv failed complaining that avahi-daemon had to be enabled before mpd, until I changed the LSB header to use avahi, not avahi-daemon.

Community
  • 1
  • 1
pwalden
  • 1
  • 3