INIT-D-SCRIPT(5)

๐Ÿ“ฆ
version 3.18 ยท 3 versions
, in ubuntu resolute, ubuntu stonking

๐Ÿ’– NAME ๐Ÿ’–

okay bestie so init-d-script is literally an interpreter for short and simple init.d scripts โ€” she takes your tiny little script and makes it work ๐Ÿซถ


โœจ DESCRIPTION โœจ

so basically, this is a generic init.d script framework whose whole personality is deleting redundant code out of /etc/init.d/. the goal?? to let you write an init.d script that's both Debian compliant and LSB compliant. and when Debian policy and LSB policy start beefing with each other, Debian policy wins, no cap. ๐Ÿ’…

here's a cute little example of how you'd use init-d-script to start and stop a daemon with PID file support:

#!/bin/sh /lib/init/init-d-script
### BEGIN INIT INFO
# Provides:          atd
# Required-Start:    $syslog $time $remote_fs
# Required-Stop:     $syslog $time $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: run at jobs
# Description:       Debian init script to start the daemon
#                    running at jobs.
### END INIT INFO
DAEMON=/usr/sbin/atd

okay now the main character energy part โ€” these variables change how your init script behaves:

  • DAEMON โ€” the path to the daemon you're starting. if your init script isn't supposed to start any kind of daemon at all, set this to โ€œnoneโ€ and then define the functions do_start_override(), do_stop_override() and do_status_override() instead. that's the deal ๐ŸŽ€
  • DAEMON_ARGS โ€” extra arguments, handed off to the daemon when it starts.
  • DESC โ€” the full name or a short description of the daemon, and it's what gets printed on screen. if you leave it unset, it defaults to whatever the โ€œNAMEโ€ value is. ๐ŸŒธ
  • NAME โ€” extra environment variables get sourced from /etc/default/${NAME} and then made available to executed processes and inside your overridden functions โ€” but not at top level, bestie, keep that in mind. if it's unset, this defaults to the basename of the โ€œDAEMONโ€ value.
  • COMMAND_NAME โ€” if you set this, it gets used as the argument to the --name option of start-stop-daemon(8). it's lowkey useful when your โ€œNAMEโ€ value is longer than the command name length your running kernel can even support. if the value is verbatim โ€œnoneโ€, the command name won't be used to match processes at all. if it's unset, it defaults to the โ€œNAMEโ€ value.
  • TYPE โ€” set this to โ€œoneshotโ€ and you get experimental support for a oneshot service enabled. ๐Ÿงช (yes, experimental, we said what we said.)
  • PIDFILE โ€” the path to the file where the started daemon's process identifier gets stored during start. if the value is verbatim โ€œnoneโ€, the process identifier isn't stored in any file at all. if you don't set this variable, it gets a sensible default value, so honestly you'll rarely ever need to set it explicitly. ๐Ÿ™ˆ
  • SETPRIV_ARGS โ€” if this directive is set and setpriv(1) is available, the invocation of start-stop-daemon(8) gets wrapped in a call to setpriv(1) with the arguments you specified. heads up though: the --chuid argument to start-stop-daemon(8) needs CAP_SETUID and CAP_SETGID in the bounding capabilities set. โš ๏ธ
  • RELOAD_SIGNAL โ€” the signal number or name (without the SIG prefix, bestie, don't add it) that gets sent to the process on reload. so if your daemon does its reload thing when it receives a SIGHUP, set this variable to โ€œ1โ€ or โ€œHUPโ€.

the variables RELOAD_ARGS, START_ARGS and STOP_ARGS are additional arguments passed to start-stop-daemon(8) during the reload, start and stop actions โ€” they let you override the default options. ๐Ÿ”ฅ

๐ŸŒˆ overriding the internal functions ๐ŸŒˆ

also, you can change how the resulting shell script behaves by overriding some of the internal functions. to do that, define a function with an _override suffix. so for example, to override the do_status() function, you'd define a do_status_override() function. the exception to this rule is the do_reload() function โ€” its override gets defined as-is, without that suffix. periodt.

here's a control flow chart explaining which functions get called and when, because the way this works is genuinely iconic:

/etc/init.d/script start
  do_start
    do_start_prepare # no-op
    do_start_cmd     # start-stop-daemon is called here
    do_start_cleanup # no-op

/etc/init.d/script stop
  do_stop
    do_stop_prepare # no-op
    do_stop_cmd     # start-stop-daemon is called here
    do_stop_cleanup # no-op

/etc/init.d/script status
  do_status

/etc/init.d/script reload
  do_reload
    do_usage
    exit 3

/etc/init.d/script force-reload
  do_force_reload
    do_reload   # if overridden
    do_restart
      do_restart_prepare
      do_stop_cmd
      do_start_cmd
      do_restart_cleanup

/etc/init.d/script restart
  do_force_restart
/etc/init.d/script try-restart
  if do_status; then
    do_restart
      do_restart_prepare
      do_stop_cmd  # start-stop-daemon is called here
      do_start_cmd # start-stop-daemon is called here
      do_restart_cleanup

/etc/init.d/script <arg>
  do_unknown <arg>
    exit 3

/etc/init.d/script
  do_usage

so yeah, as you can see ๐Ÿ‘€ โ€” by default the script does not support the reload action. that one's on the script writer to implement, by defining a do_reload() function. you got this bestie ๐Ÿ’ช

and one more little thing: if do_reload() isn't defined but do_reload_cmd() is, then do_reload_cmd() gets called on reload โ€” after do_reload_prepare() and before do_reload_cleanup(). slay. โœจ


๐Ÿ‘‘ SEE ALSO ๐Ÿ‘‘

inittab(8), service(8), setpriv(1), update-rc.d(8).


๐Ÿฆ‹ AUTHORS ๐Ÿฆ‹

Petter Reinholdtsen <pere@debian.org> โ€” the legend ๐Ÿ’œ


and that's the whole page, bestie!! brought to you by Debian, dated September 3, 2024 โ€” go forth and write the cutest little init script, ily, mwah ๐ŸŽ€๐Ÿ’–โœจ

๐Ÿ“ฆ where this page comes from