Debian – How to find out in which order /etc/init.d scripts are load on Debian

With insserv virtual boot facilities allow init scripts to depend on widely used functionnalities provided by groups of differents scripts or by various methods accross distributions.

Depending on the $network target means that a configured network connection is needed. In Debian it means running the networking and ifupdown initscripts, as described in insserv.conf.

$local_fs is used for almost every startup script as it means that every local filesystems will be mounted, $remote_fs is obviously dependant of $network.

The scripts needed to reach this goals are not named the same on every distribution and can change from one OS version to another. As insserv can be configured differently to reflect this changes the initscripts depending on this facilities dont need to be changed for each particular case.

The idea at the time of the design of this standart by the LSB was to make init scripts less distribution dependant, something which is now provided by systemd in most distributions.

I don't know specifically about an init.d file, but a udev rule for running a script upon device-add might look like:

ACTION=="add", ATTRS{idVendor}=="VID", ATTRS{idProduct}=="PID", RUN+="/path/to/executable"

You should do some digging in udevadm to learn more about the way the device is typically added and its modules loaded. You'll also find the correct values for VID and PID in there.

Does it accept a combination of both device and kernel module?

Yes. Well... no. Maybe? The answer to this question entirely depends on the level at which you intercept the device-add. udev has to do many things from the point at which it initially detects a device to the point at which it has fully loaded and initialized the device and it can be considered up.

Some of these things are likely:

• initially detecting the hardware on its parent bus/device/subsystem

• finding and loading the appropriate kernel module

• populating the /dev devfs file system with the appropriate device special file

• detecting any child-devices the current device adds and rinse, repeat

You can specify a rule for all or any of these levels of action. You can also udevadm trigger or monitor or several other things directly in real-time to determine exactly what these levels of action might be.

I recommend you look closely at this information if you wish to become more familiar with it.