INSSERV(8)
๐ธ INSSERV(8) โ the manual page, but make it make sense ๐ธ
okay bestie, sit down, we're doing insserv from the System Manager's Manual section 8, and honestly? it's giving boot sequence royalty. ๐
โจ NAME โจ
insserv โ boot sequence organizer using LSB init.d script dependency information
like, it literally organizes your boot sequence. that's the whole job. ๐
โจ SYNOPSIS โจ
insserv [-v] [-c <config>] [-p <path>] [-d] [-f]
[[/]path/to/init.d/]script ...
insserv [-v] [-c <config>] [-p <path>]
[[/]path/to/init.d/]script[,start=<lvl1,lvl2,...>,stop=<lvl1,lvl2,...>]
insserv [-v] [-c <config>] [-p <path>] -r [-d] [-f]
[[/]path/to/init.d/]script ...
insserv -h
four whole moods. pick your fighter. ๐ซถ
โจ DESCRIPTION โจ
so insserv is a low level tool used by update-rc.d โ it's the backstage crew, not the main character โ and what it does is enable an installed system init script (aka a boot script) by reading the comment header of the script. and the header looks exactly like this, no cap:
### BEGIN INIT INFO
# Provides: boot_facility_1 [ boot_facility_2 ...]
# Required-Start: boot_facility_1 [ boot_facility_2 ...]
# Required-Stop: boot_facility_1 [ boot_facility_2 ...]
# Should-Start: boot_facility_1 [ boot_facility_2 ...]
# Should-Stop: boot_facility_1 [ boot_facility_2 ...]
# X-Start-Before: boot_facility_1 [ boot_facility_2 ...]
# X-Stop-After: boot_facility_1 [ boot_facility_2 ...]
# Default-Start: run_level_1 [ run_level_2 ...]
# Default-Stop: run_level_1 [ run_level_2 ...]
# X-Interactive: true
# Short-Description: single_line_description
# Description: multiline_description
### END INIT INFO
and then it calculates the dependencies between all the scripts. literally all of them. ๐
โ ๏ธ the vibe check that matters: it is not recommended to executeinsservdirectly unless you know exactly what you're doing. doing so may render your boot system inoperable. like, bricked. dead. ๐update-rc.dis the recommended interface for managing init scripts, bestie. please use it. ๐
okay so now, the keywords:
The Default-Start keyword declares on which runlevels the script must be started. An empty value means the script will never be started. and the same applies for its counterpart Default-Stop, with the only difference being that the script will be stopped. (yes queen, symmetry โจ)
please be aware that the line
# Required-Stop: boot_facility_1 [ boot_facility_2 ...]
declares facilities which must be available during shutdown of the service declared in the Provides tag. same holds true for
# Should-Stop: boot_facility_1 [ boot_facility_2 ...]
which declares facilities which should be available during shutdown of the service declared in the Provides tag. in both cases the script system should avoid stopping services which are declared by these two Stop tags until the script including these tags is stopped. so likeโฆ don't yank the rug out from under them. ๐ง
the optional X-Interactive keyword implies that the script using this keyword should be started alone in a concurrent boot configuration, because it interacts with the user at the console. only the value true is recognised โ all others are ignored. (sorry to the other values, you're not invited ๐)
the optional X-Start-Before keyword implies that the script using this keyword should be started before the specified service names. whereas the optional X-Stop-After keyword implies that the script using this keyword should be stopped after the specified service names. both imply that those services now depend on the specifying script. with known dependencies and runlevel(s), insserv sets and reorders the corresponding symbolic links of the concerned runlevels directories. iconic behavior. ๐
๐ธ system facilities & the config file ๐ธ
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). all names followed by such a system facility will declare the required dependencies of the facility. here's an example for /etc/insserv.conf:
# All local filesystems are mounted
# (done during boot phase)
$local_fs boot
# Low level networking
$network network route
# Named is operational
$named named
# All remote filesystems are mounted
# (in some cases /usr may be remote).
$remote_fs $local_fs nfs
# System logger is operational
$syslog syslog
# All network daemons are running (This was removed in LSB 1.2)
$netdaemons portmap inetd
# Services which need to be interactive
<interactive> boot.crypto
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. (no drama, no complaints, she just moves on ๐ฆ)
words beginning with < and ending with > are keywords. currently <interactive> is the only known keyword for marking a service as an interactive one โ e.g., a service which requires a passphrase or password input during boot or runlevel change. the special facility $null is used to enforce an empty dependency in case of Should-Stop and Required-Stop.
in addition to the defined System Facilities in the configuration file /etc/insserv.conf, insserv also knows the special facility $all. this facility indicates that a service should be inserted at the end of all services at starting and at the very beginning at stopping. clearly all services using this facility will be grouped into one starting or stopping order. periodt. ๐
โจ OPTIONS โจ
currently the following options are recognized by insserv:
-v,--verboseโ perform the operation with more diagnostic messages printed onstderr. she's chatty, she's telling you everything โจ-q,--silentโ perform operations silently. this blocks warning messages from being printed tostderr. only fatal error messages are printed. so like, quiet but not too quiet ๐-c <config>,--config <config>โ specify path to theinsserv.conffile (by default located at/etc/insserv.conf). this is typically used for testing purposes.insserv(8)will automatically check for the existence of an insserv configuration directory under this location. for example, specifying/usr/local/etc/insserv.confwill causeinsservto also scan the directory/usr/local/etc/insserv.conf.d/๐-i,--insserv-dirโ theinsservprogram will try to place dependency information in the/etc/init.ddirectory. when using the-iflag, the user can specify an alternative directory for dependency information. this is typically used when debugginginsserv. ๐ง-o <path>,--override <path>โ LSB comment headers found in this path will override existing LSB comment headers of scripts in theinit.ddirectory (default path is/etc/insserv/overrides/). override queen ๐-p <path>,--path <path>โ specify path toinit.ddirectory. useful for testing. ๐-n,--dryrun,--dry-runโ do not update symlinks. does not createdepend.boot,depend.start, anddepend.stopfiles. it's giving pretend ๐-s,--showall,--show-allโ output runlevel and sequence information. do not update symlinks. just show, don't touch. ๐-r,--removeโ remove the listed scripts from all runlevels. bye bestie ๐ซถ-d,--defaultโ use default runlevels as defined in the scripts. this may restore an edited runlevel link scheme. the glow-up back to factory settings โจ-f,--forceโ ignore if a required service is missed. beside this, if start and or stop levels are specified on the command line the default levels of the script will be ignored. force = main character energy, no rules ๐-u <path>,--upstart-job <path>โ path to replace existing upstart job path. (default path is/lib/init/upstart-job). ๐ง-h,--helpโ print out short usage message. the classic "help me" ๐
but you may use the argument syntax described in the following section. and you will, because it slays.
โจ ARGUMENTS โจ
[[/]path/to/init.d/]โ relative or absolute path to the init scripts base directory. this defaults to/etc/init.d/in compliance with the LSB specification. in this caseinsservdoes not add or remove a script to the runlevels declared in the script headers, but may re-order the runlevels if the order of the currently enabled scripts has changed (see option-d). note that if a relative path is used,insservhas to be called from the root directory. ๐ซถ[[/]path/to/init.d/]script ...โ list of scripts which have to be added to the runlevels. if a path is used it should point to the absolute or relative location of the boot scripts.insservchecks for the existence of these scripts. for the runlevels the information found in the script is used. ๐[[/]path/to/init.d/]script[,start=<lvl1,lvl2,...>]โ list of scripts which have to be added to the specified runlevels to be started with. you may use this extension to override the default values for start and stop runlevels of the script. note that lvl1, lvl2, โฆ are the known runlevels explained above. the extension,stop=<lvl1,lvl2,...>is also possible. โจ-r [[/]path/to/init.d/]script ...โ list of scripts which should be removed from the runlevels. if a path is used it should point to the absolute or relative location of the boot scripts.insservchecks for the existence of these scripts. ๐ซถ
โจ OVERRIDES โจ
beside using the extensions ,start=<lvl1,lvl2,...> and ,stop=<lvl1,lvl2,...>, it is possible to use override files to replace an LSB comment header or simply provide a missing LSB comment header. this can be done by placing a file with the new LSB comment header using the same name as the boot or init script in the directory /etc/insserv/overrides/. for third party boot scripts without an LSB header, it is possible to add a file with the same name in the directory /usr/share/insserv/overrides/ to make them completely LSB compliant. glow-up via file name matching, iykyk ๐
โจ UPSTART JOB COMPATIBILITY โจ
to allow upstart jobs to work as init.d scripts, insserv will recognize a symlink from path/to/init.d/script to /lib/init/upstart-job as upstart jobs, and instead of reading the header from the file, it will run the script with the argument lsb-header to get the script header. sneaky? no. genius. ๐
โจ EXIT CODES โจ
the exit codes have the following conditions:
0โ Service was successfully installed or removed1โ Service was not installed or removed
like, two moods. that's it. ๐ธ
okay and that's not even the whole thing โ more parts are coming, bestie, so don't go anywhere ๐
โจ NOTE โจ
Okay bestie, listen up, because this is a vibe check for your boot script file names ๐
. Heads up: insserv will not accept these patterns of boot script file names:
*.dpkg*
*.ucf*
*.rpm*
*.ba*
*.old
*.new
*.org
*.orig
*.save
*.swp
*.core
*~
That's with the wildcard character *, no cap ๐ซถ.
Also, all boot script file names that begin with one of these characters:
$.#%_+-\*[]^:()~
will be ignored. Like, straight up ghosted ๐ป.
Administrators can further filter files by extension in the /etc/init.d/ directory by creating a text file called /etc/insserv/file-filters โจ. The file-filters configuration file lists โ one per line โ extensions that should be ignored by insserv as it parses the /etc/init.d/ directory. An example of /etc/insserv/file-filters might look like this:
git
svn
html
So cute, so organized ๐.
๐ BUGS ๐
Boot scripts sometimes lack a LSB comment header ๐ญ. If that's happening, contact a package maintainer or developer of the software which provides the script to have a LSB comment header added to it. Slay responsibly.
๐ FILES ๐
/etc/insserv.confโ configuration file forinsservwhich defines the LSB System Facilities ๐./etc/insserv.conf.d/โ directory for further configuration files for declaring LSB System Facilities ๐๏ธ./etc/insserv/overrides/โ path to replace existing LSB comment headers with the comment headers found in this path ๐./etc/insserv/file-filtersโ configuration file which lists file extensions (one per line) we should ignore when parsing theinit.ddirectory ๐งน./etc/init.d/โ path to the init script base directory as required by the Linux Standard Base Specification (LSB) ๐ง./etc/init.d/.depend.boot,/etc/init.d/.depend.start,/etc/init.d/.depend.stopโ Themake(1)like dependency files produced byinsservfor booting, starting, and stopping with the help ofstartpar(1)โ๏ธ.
๐ SEE ALSO ๐
Like, go read those too, they're giving main character energy ๐.
ยฉ๏ธ COPYRIGHT ยฉ๏ธ
2000โ2009Werner Fink,2009SuSE Linux Products GmbH Nuernberg, Germany.2000โ2003SuSE GmbH Nuernberg, Germany,2007โ2009SuSE Linux Products GmbH Nuernberg, Germany.2019โJesse Smith
โ๏ธ AUTHOR โ๏ธ
Werner Fink <feedback@suse.de>
๐ซถ CONTRIBUTORS ๐ซถ
- Petter Reinholdtsen
- Kel Modderman
And that's the whole page, bestie ๐. This iconic manual is from the 3rd Berkeley Distribution, dated July 29, 2008, and it's literally INSSERV(8). Periodt. ๐
โจ
๐ฆ where this page comes from
- debian trixie: insserv 1.26.0-1
- Copyright 2000-2009 Werner Fink
- Copyright 2000-2003 SuSE GmbH Nuernberg, Germany
- Copyright 2007-2009 SuSE Linux Products GmbH Nuernberg, Germany
- Copyright 2009 Petter Reinholdtsen
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms