openrc-run(8)

πŸ“¦
version 0.63.2 Β· 4 versions
, in alpine 3.24

πŸŽ€ openrc-run(8) πŸŽ€

From the System Manager's Manual, bestie. This is the whole vibe.


✨ NAME ✨

openrc-run β€” a means of hooking shell commands into a service. Literally the glow-up between your scripts and the service world.


πŸ’« SYNOPSIS πŸ’«

openrc-run [-D, --nodeps] [-d, --debug] [-s, --ifstarted]
           [-S, --ifstopped] [-Z, --dry-run] [command ...]

🌸 DESCRIPTION 🌸

Okay so openrc-run is basically an interpreter for shell scripts, and it gives you an easy interface to the often complex system commands and daemons. It's giving "translator, but make it Unix."

When a service runs a command, it first loads its multiplexed configuration file, then its master configuration file, then /etc/rc.conf, and finally the script itself. At that point, openrc-run runs the command given. Order matters, bestie β€” it's not a free-for-all.

Commands are defined as shell functions within the script. Here's a list of some functions that all scripts have by default:

🧚 the default command squad

  • describe β€” describes what the service does and each command the service defines.
  • start β€” first we ensure that any services we depend on are started. If any needed services fail to start, we exit with a suitable error; otherwise we call the supplied start function if it exists.
  • stop β€” first we ensure that any services that depend on us are stopped. If any services that need us fail to stop, we exit with a suitable error; otherwise we call the supplied stop function if it exists.
  • restart β€” stops and starts the service, including dependencies. This cannot be overridden. See the description of the RC_CMD variable below for the method to make your service behave differently when restart is being executed.
  • status β€” shows the status of the service. The return code matches the status, with the exception of started returning 0 to match standard command behaviour.
  • zap β€” resets the service state to stopped and removes all saved data about the service.

πŸŽ€ options / flags

  • -d, --debug β€” sets xtrace on in the shell to assist in debugging.
  • -D, --nodeps β€” ignores all dependency information the service supplies.
  • -s, --ifstarted β€” only runs the command if the service has been started.
  • -S, --ifstopped β€” only runs the command if the service has been stopped.
  • -q, --quiet β€” turns off all informational output the service generates. Output from any non-OpenRC commands is not affected.
  • -v, --verbose β€” turns on any extra informational output the service generates.
  • -Z, --dry-run β€” shows which services would be stopped and/or started without actually stopping or starting them.

πŸ’– variables you can set

  • extra_commands β€” space-separated list of extra commands the service defines. These should not depend on the service being stopped or started.
  • extra_started_commands β€” space-separated list of extra commands the service defines. These only work if the service has already been started.
  • extra_stopped_commands β€” space-separated list of extra commands the service defines. These only work if the service has already been stopped.
  • description β€” string describing the service.
  • description_$command β€” string describing the extra command.
  • supervisor β€” supervisor to use to monitor this daemon. If this is unset or invalid, start-stop-daemon will be used. Currently, we support s6 from skarnet software, and supervise-daemon, which is a light-weight supervisor internal to OpenRC. To use s6, set supervisor=s6, or set supervisor=supervise-daemon to use supervise-daemon.
  • s6_service_path β€” the path to the s6 service directory if you are monitoring this service with S6. The default is /var/svc.d/${RC_SVCNAME}.
  • s6_svwait_options_start β€” the options to pass to s6-svwait when starting the service via s6.
  • s6_force_kill β€” should we force-kill this service if s6_service_timeout_stop expires but the service doesn't go down during shutdown? The default is yes.
  • s6_service_timeout_stop β€” the amount of time, in milliseconds, s6-svc should wait for the service to go down when stopping the service. The default is 60000.
  • start_stop_daemon_args β€” list of arguments passed to start-stop-daemon when starting the daemon.
  • supervise_daemon_args β€” list of arguments passed to supervise-daemon when starting the daemon. If undefined, start_stop_daemon_args is used as a fallback.
  • command β€” daemon to start or stop via start-stop-daemon or supervise-daemon if no start or stop function is defined by the service.
  • command_args β€” list of arguments to pass to the daemon when starting via start-stop-daemon.
  • command_args_background β€” this variable should be used if the daemon you are starting with start-stop-daemon(8) runs in the foreground by default but has its own command line options to request that it background and write a pid file. It should be set to those options. It should not be used at the same time as command_background, because command_background requests that start-stop-daemon(8) go into the background before executing the daemon.
  • command_args_foreground β€” list of arguments to pass to the daemon when starting via supervise-daemon, to force the daemon to stay in the foreground.
  • command_background β€” set this to "true", "yes" or "1" (case-insensitive) if you want start-stop-daemon(8) to force the daemon into the background. This forces the --make-pidfile and --pidfile options, so the pidfile variable must be set.
  • command_progress β€” set this to "true", "yes" or "1" (case-insensitive) if you want start-stop-daemon(8) to display a progress meter when waiting for a daemon to stop.
  • command_user β€” if the daemon does not support changing to a different user id, you can use this to change the user id, and optionally group id, before start-stop-daemon(8) or supervise-daemon(8) launches the daemon.
  • input_file β€” this is the path to a file or named pipe to which the standard input of the service will be redirected to. If you are starting this service with start-stop-daemon(8), you must set command_background to true. Keep in mind that this path will be inside the chroot if the chroot variable is set. Contrary to output and error redirection, input redirection assumes that the file exists already.
  • output_log β€” the same thing as input_file but for the standard output.
  • error_log β€” the same thing as input_file but for the standard error output.
  • output_logger β€” this is a process which will be used to log the standard output from the service. If you are starting this service with start-stop-daemon(8), you must set command_background to true. Keep in mind that this command must be executable as a shell command inside the chroot if the chroot variable is set. Keep in mind also that this command works by accepting the stdout of the service on stdin. An example of a command that can be run this way is logger if you want your service output to go to syslog.
  • error_logger β€” the same thing as output_logger but for the standard error output.
  • directory β€” start-stop-daemon(8) and supervise-daemon(8) will chdir to this directory before starting the daemon.
  • chroot β€” start-stop-daemon(8) and supervise-daemon(8) will chroot into this path before writing the pid file or starting the daemon.
  • pidfile β€” pidfile to use for the above defined command.
  • name β€” display name used for the above defined command.
  • procname β€” process name to match when signaling the daemon.
  • stopsig β€” signal to send when stopping the daemon.
  • respawn_delay β€” respawn delay supervise-daemon(8) will use for this daemon. See supervise-daemon(8) for more information about this setting.
  • respawn_max β€” respawn max supervise-daemon(8) will use for this daemon. See supervise-daemon(8) for more information about this setting.
  • respawn_period β€” respawn period supervise-daemon(8) will use for this daemon. See supervise-daemon(8) for more information about this setting.
  • retry β€” retry schedule to use when stopping the daemon. It can either be a timeout in seconds or multiple signal/timeout pairs (like SIGTERM/5).
  • required_dirs β€” a list of directories which must exist for the service to start.
  • required_files β€” a list of files which must exist for the service to start.
  • start_inactive β€” set to yes to have the service marked inactive when it starts. This is used along with in_background_fake to support re-entrant services.
  • in_background_fake β€” space-separated list of commands which should always succeed when in_background is yes.
  • umask β€” set the umask of the daemon.

🫢 eval heads-up

Keep in mind that eval is used to process chroot, command, command_args_*, command_user, pidfile and procname. This may affect how they are evaluated depending on how they are quoted. So quote like you mean it, bestie.

  • notify β€” this is how your daemon slides into the service manager's DMs to say "bestie, I'm up πŸ’…". Accepted values are fd:num, which expects a newline in the open file descriptor num when the daemon is ready, and socket:ready, which will export $NOTIFY_SOCKET and listen for notifications. At the moment it supports READY=1 β€” that's the one vibe it's checking for, periodt.

🌸 Default start/stop 🌸

Okay so here's the whole gossip chart of which variables actually get used by the default start and stop functions, and where each one shows up. The columns are start-stop-daemon, supervise-daemon, and s6, and a β€” just means "not used there, she's off duty πŸ™ˆ".

  • capabilities β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: β€”
  • chroot β€” start-stop-daemon: start Β· supervise-daemon: start,stop Β· s6: start
  • command β€” start-stop-daemon: stop Β· supervise-daemon: stop Β· s6: start
  • command_args β€” start-stop-daemon: β€” Β· supervise-daemon: β€” Β· s6: start
  • command_args_foreground β€” start-stop-daemon: β€” Β· supervise-daemon: β€” Β· s6: start
  • command_user β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: start
  • directory β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: start
  • error_log β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: start
  • error_logger β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: start
  • healthcheck_delay β€” start-stop-daemon: β€” Β· supervise-daemon: start Β· s6: β€”
  • healthcheck_timer β€” start-stop-daemon: β€” Β· supervise-daemon: start Β· s6: β€”
  • input_file β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: start
  • no_new_privs β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: β€”
  • notify β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: start
  • output_log β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: start
  • output_logger β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: start
  • pidfile β€” start-stop-daemon: start,stop Β· supervise-daemon: start,stop Β· s6: β€”
  • procname β€” start-stop-daemon: start,stop Β· supervise-daemon: β€” Β· s6: β€”
  • respawn_delay β€” start-stop-daemon: β€” Β· supervise-daemon: start Β· s6: β€”
  • respawn_max β€” start-stop-daemon: β€” Β· supervise-daemon: start Β· s6: β€”
  • respawn_period β€” start-stop-daemon: β€” Β· supervise-daemon: start Β· s6: β€”
  • retry β€” start-stop-daemon: stop Β· supervise-daemon: start Β· s6: β€”
  • s6_log_arguments β€” start-stop-daemon: β€” Β· supervise-daemon: β€” Β· s6: start
  • secbits β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: β€”
  • stopsig β€” start-stop-daemon: stop Β· supervise-daemon: β€” Β· s6: stop
  • supervise_daemon_args β€” start-stop-daemon: β€” Β· supervise-daemon: start Β· s6: β€”
  • timeout_down β€” start-stop-daemon: β€” Β· supervise-daemon: β€” Β· s6: stop
  • timeout_kill β€” start-stop-daemon: β€” Β· supervise-daemon: β€” Β· s6: stop
  • timeout_ready β€” start-stop-daemon: β€” Β· supervise-daemon: β€” Β· s6: start
  • umask β€” start-stop-daemon: start Β· supervise-daemon: start Β· s6: start

✨ Ambient process capabilities ✨

So on Linux your processes have ✨ambient capabilities✨ and these options are the ones that mess with them. Go read capabilities(7) if you want the full lore, bestie β€” it's giving required reading.

  • no_new_privs β€” sets no_new_privs on the daemon process, which means it literally cannot gain any additional privilege, including through setuid/setgid binaries, file capabilities, etc. Like, the privilege glow-up is cancelled πŸ”₯.
  • capabilities CAPABILITIES β€” sets additional ambient capabilities for the process. Give her the power-ups, you decide which ones πŸ‘‘.
  • secbits AR SECBITS β€” sets the -securebits for the process, which adjusts how the kernel treats ambient capabilities for this process. Yeah it's very "trust me the kernel knows what it's doing" energy, but that's the deal 🫢.

πŸ’… DEPENDENCIES πŸ’…

okay bestie, listen β€” you gotta define a depend function for your service so openrc-run knows the ✨order✨ to start and stop it in relative to all the other services. and because it's a function, it can be seriously flexible β€” the example is down below, keep reading 🫢

here's the whole menu of functions you can use inside a depend function. the way it works: you just pass the names of the services you want to add to that dependency type to the function, or β€” fun trick β€” prefix the names with ! to remove them from the dependencies πŸŽ€

  • need β€” the service will attempt to start any services it needs regardless of whether they've been added to the runlevel. it will refuse to start until all the services it needs have started, and it will refuse to stop until all the services that need it have stopped. highkey the strictest one πŸ’€
  • use β€” the service will attempt to start any services it uses that have been added to the runlevel.
  • want β€” the service will attempt to start any services it wants, regardless of whether they've been added to the runlevel.
  • after β€” the service will start after these services and stop before these services.
  • before β€” the service will start before these services and stop after these services.
  • provide β€” the service provides this virtual service. for example, named provides dns. 🩡 note that it is not legal to have a virtual and real service with the same name. if you do this, you will receive an error message, and you must rename either the real or virtual service. no cap.
  • config β€” we should recalculate our dependencies if the listed files have changed.
  • keyword β€” tags a service with a keyword. these are the keywords we currently understand:
    • -shutdown β€” don't stop this service when shutting the system down. this is normally quite safe as remaining daemons will be sent a SIGTERM just before final shutdown. network related services such as the network and dhcpcd init scripts normally have this keyword.
    • -stop β€” don't stop this service when changing runlevels, even if not present. this includes shutting the system down.
    • -timeout β€” other services should wait indefinitely for this service to start. use this keyword if your service may take longer than 60 seconds to start. ⏳
    • -jail β€” when in a jail, exclude this service from any dependencies. the service can still be run directly. set via rc_sys in /etc/rc.conf.
    • -lxc β€” same as -jail, but for Linux Resource Containers (LXC).
    • -openvz β€” same as -jail, but for OpenVZ systems.
    • -prefix β€” same as -jail, but for Prefix systems.
    • -rkt β€” same as -jail, but for RKT systems.
    • -uml β€” same as -jail, but for UML systems.
    • -vserver β€” same as -jail, but for VServer systems.
    • -xen0 β€” same as -jail, but for Xen DOM0 systems.
    • -xenu β€” same as -jail, but for Xen DOMU systems.
    • -docker β€” same as -jail, but for docker systems. 🐳
    • -podman β€” same as -jail, but for podman systems.
    • -containers β€” same as -jail, but for all relevant container types on the operating system. it's giving "all of the above" energy πŸ‘‘

to see how to influence dependencies in configuration files, see the β€œFILES” section below πŸ‘€


🧚 _pre AND _post FUNCTIONS 🧚

so any command defined in extra_commands, extra_started_commands or extra_stopped_commands can have _pre and _post functions in the service script. like, if the command function is called foo, then the _pre and _post functions for it should be called foo_pre and foo_post. naming consistency iconique ✨

what are they for? these functions should be used to perform preparation before the command is run and cleanup after the command completes. think of them as the getting-ready-and-then-tidying-up of your service script πŸ’…

and here's the important bit β€” in order for openrc-run to record the command as being run successfully, the _pre function, the command function itself and the _post function should all exit with a zero return code. all three, bestie. no shortcuts. 🫢


πŸ‘‘ BUILTINS πŸ‘‘

openrc-run defines some builtin functions that you can use inside your service scripts. these are the little helpers that make your output cute and your checks easy 🌸

  • einfo [string] β€” output a green asterisk followed by the string. πŸ’š
  • ewarn [string] β€” output a yellow asterisk followed by the string. πŸ’›
  • eerror [string] β€” output a red asterisk followed by the string to stderr. ❀️
  • ebegin [string] β€” same as einfo, but append 3 dots to the end.
  • eend retval [string] β€” if retval does not equal 0 then output the string using eerror and !! in square brackets at the end of the line. otherwise output ok in square brackets at the end of the line. the value of retval is returned.
  • ewend retval [string] β€” same as eend, but use ewarn instead of eerror.

and the glow-up: you can prefix the above commands with the letter v, which means they only output when the environment variable EINFO_VERBOSE is true. quiet mode stays quiet 🀫

  • ewaitfile timeout file1 file2 ... β€” wait for timeout seconds until all files exist. returns 0 if all files exist, otherwise non zero. if timeout is less than 1 then we wait indefinitely. (patience is a virtue, apparently 😭)
  • is_newer_than file1 file2 ... β€” if file1 is newer than file2 return 0, otherwise 1. if file2 is a directory, then check all its contents too.
  • is_older_than file1 file2 ... β€” if file1 is newer than file2 return 0, otherwise 1. if file2 is a directory, then check all its contents too. (yes, that's literally the same wording as is_newer_than β€” that's what the page says, iykyk πŸ™ˆ)
  • service_set_value name value β€” saves the name value for later retrieval. saved values are lost when the service stops. so don't get attached πŸ₯²
  • service_get_value name β€” returns the saved value called name.
  • service_started [service] β€” if the service is started, return 0 otherwise 1.
  • service_starting [service] β€” if the service is starting, return 0 otherwise 1.
  • service_inactive [service] β€” if the service is inactive, return 0 otherwise 1.
  • service_stopping [service] β€” if the service is stopping, return 0 otherwise 1.
  • service_stopped [service] β€” if the service is stopped, return 0 otherwise 1.
  • service_coldplugged [service] β€” if the service is coldplugged, return 0 otherwise 1.
  • service_wasinactive [service] β€” if the service was inactive, return 0 otherwise 1.
  • service_started_daemon [service] daemon [index] β€” if the service has started the daemon using start-stop-daemon, return 0 otherwise 1. if an index is specified, it has to be the nth daemon started by the service.
  • mark_service_started [service] β€” mark the service as started.
  • mark_service_starting [service] β€” mark the service as starting.
  • mark_service_inactive [service] β€” mark the service as inactive.
  • mark_service_stopping [service] β€” mark the service as stopping.
  • mark_service_stopped [service] β€” mark the service as stopped.
  • mark_service_coldplugged [service] β€” mark the service as coldplugged.
  • mark_service_wasinactive [service] β€” mark the service as inactive. (yes, that's what it says β€” inactive, bestie, we don't make the rules 🫠)

πŸ¦‹ checkpath πŸ¦‹

  • checkpath [-D, --directory-truncate] [-d, --directory] [-F, --file-truncate] [-f, --file] [-p, --pipe] [-m, --mode mode] [-o, --owner owner] [-s, --symlinks] [-W, --writable] [-q, --quiet] path ... β€” okay so this one's a whole little toolkit:
    • if -d, -f or -p is specified, checkpath checks to see if the path exists, is the right type and has the correct owner and access modes. if any of these tests fail, the path is created and set up as specified. if more than one of -d, -f or -p are specified, the last one will be used. last one wins, periodt.
    • the argument to -m is a three or four digit octal number. if this option is not provided, the value defaults to 0644 for files and 0775 for directories. defaults slay πŸ’…
    • the argument to -o is a representation of the user and/or group which should own the path. the user and group can be represented numerically or with names, and are separated by a colon.
    • the truncate options (-D and -F) cause the directory or file to be cleared of all contents. so like, everything gone. you've been warned πŸ’€
    • if -s is not specified on a non-linux platform, checkpath will refuse to allow non-terminal symbolic links to exist in the path. this is for security reasons so that a non-root user can't create a symbolic link to a root-owned file and take ownership of that file. πŸ”’ protect the root files fr fr
    • if -W is specified, checkpath checks to see if the first path given on the command line is writable. this is different from how the test command in the shell works, because it also checks to make sure the file system is not read only.
    • the -q option suppresses all informational output. if it is specified twice, all error messages are suppressed as well. 🀐

πŸ“ fstabinfo πŸ“

  • fstabinfo [-M, --mount] [-R, --remount] [-b, --blockdevice] [-m, --mountargs] [-o, --options] [-p, --passno passno] [-t, --type fstype] path β€” if -b, -m, -o, -p or -t is specified, the appropriate information is extracted from fstab. if -M or -R are given, file systems are mounted or remounted. 🧚
    • the -q option suppresses all informational output. if it is specified twice, all error messages are suppressed as well.

🌈 mountinfo 🌈

  • mountinfo [-f, --fstype-regex regex] [-F, --skip-fstype-regex regex] [-n, --node-regex regex] [-N, --skip-node-regex regex] [-o, --options-regex regex] [-O, --skip-options-regex regex] [-p, --point-regex regex] [-P, --skip-point-regex regex] [-e, --netdev] [-E, --nonetdev] [-i, --options] [-s, --fstype] [-t, --node] mount1 mount2 ... β€” the f, F, n, N, o, O, p, P, e and E options specify what you want to search for or skip in the mounted file systems. the i, s and t options specify what you want to display. if no mount points are given, all mount points will be considered. search, skip, display β€” pick your fighter ⭐

πŸŽ€ yesno πŸŽ€

  • yesno value β€” if value matches YES, TRUE, ON or 1 regardless of case then we return 0, otherwise 1. not me checking all four spellings for you 🫢

πŸ’– ENVIRONMENT πŸ’–

okay so openrc-run sets these environment variables for you to use inside your service scripts, bestie β€” memorize the vibes, not the stress πŸ’…

  • RC_SVCNAME β€” the name of the service. literally its whole identity ✨
  • RC_SERVICE β€” the full path to the service. iconic full-address energy 🏑
  • RC_RUNLEVEL β€” the current runlevel OpenRC is in. heads up: in OpenRC, the reboot runlevel is mapped to the shutdown runlevel. why? because most services do not need to know if the system is shutting down or rebooting. if you're writing a service that does need to know, go check the RC_REBOOT variable πŸ‘€
  • RC_REBOOT β€” contains YES if the system is rebooting. if your service needs to know the system is rebooting, test this variable. that's the one, no cap 🫢
  • RC_BOOTLEVEL β€” the boot runlevel chosen. default is boot.
  • RC_DEFAULTLEVEL β€” the default runlevel chosen. default is default.
  • RC_SYS β€” a special variable that describes the system more. possible values are OPENVZ, XENU, XEN0, UML and VSERVER. system lore fr 🧚
  • RC_UNAME β€” the result of uname -s.
  • RC_CMD β€” contains the name of the command the service script is executing, such as start, stop, restart etc. one example of using this is to make a service script behave differently when restart is being executed. main character command awareness πŸ’«
  • RC_GOINGDOWN β€” contains YES if the system is going into single user mode or shutting down.
  • RC_LIBEXECDIR β€” the value of libexecdir which OpenRC was configured with during build time.
  • RC_NO_UMOUNTS β€” used by plugins to contain a list of directories which should not be unmounted. protected directories, we love to see it πŸ›‘οΈ

πŸŽ€ FILES πŸŽ€

Configuration files, relative to the location of the service. If a file ending with .${RC_RUNLEVEL} exists, then we use that instead. slay, runlevel-specific config πŸ’…

  • ../conf.d/${RC_SVCNAME%%.*} β€” multiplexed configuration file. example: if ${RC_SVCNAME} is net.eth1 then look for ../conf.d/net.
  • ../conf.d/${RC_SVCNAME} β€” service configuration file.
  • /etc/rc.conf β€” host configuration file.

With the exception of /etc/rc.conf, the configuration files can also influence the dependencies of the service through variables. simply prefix the name of the dependency with rc_. examples bestie:

# Whilst most services don't bind to a specific interface, our
# openvpn configuration requires a specific interface, namely bge0.
rc_need="net.bge0"
# To put it in /etc/rc.conf you would do it like this
rc_openvpn_need="net.bge0"

# Services should not depend on the tap1 interface for network,
# but we need to add net.tap1 to the default runlevel to start it.
rc_provide="!net"
# To put it in /etc/conf.d/net you would do it like this
rc_provide_tap1="!net"
# To put in in /etc/rc.conf you would do it like this
rc_net_tap1_provide="!net"

# It's also possible to negate keywords. This is mainly useful for prefix
# users testing OpenRC.
rc_keyword="!-prefix"
# This can also be used to block a script from running in all
# containers except one or two
rc_keyword="!-containers !-docker"

🌈 EXAMPLES 🌈

An example service script for foo. this is giving full main character service script energy πŸ‘‘

#!/sbin/openrc-run
command=/usr/bin/foo
command_args="${foo_args} --bar"
pidfile=/var/run/foo.pid
name="FooBar Daemon"

description="FooBar is a daemon that eats and drinks"
extra_commands="show"
extra_started_commands="drink eat"
description_drink="Opens mouth and reflexively swallows"
description_eat="Chews food in mouth"
description_show="Shows what's in the tummy"

_need_dbus()
{
    grep -q dbus /etc/foo/plugins
}

depend()
{
    # We write a pidfile and to /var/cache, so we need localmount.
    need localmount
    # We can optionally use the network, but it's not essential.
    use net
    # We should be after bootmisc so that /var/run is cleaned before
    # we put our pidfile there.
    after bootmisc

    # Foo may use a dbus plugin.
    # However, if we add the dbus plugin whilst foo is running and
    # stop dbus, we don't need to stop foo as foo didn't use dbus.
    config /etc/foo/plugins
    local _need=
    if service_started; then
        _need=`service_get_value need`
    else
        if _need_dbus; then
           _need="${_need} dbus"
        fi
    fi
    need ${_need}
}

# This function does any pre-start setup. If it fails, the service will
# not be started.
# If you need this function to behave differently for a restart command,
# you should check the value of RC_CMD for "restart".
# This also applies to start_post, stop_pre and stop_post.
start_pre()
{
        if [ "$RC_CMD" = restart ]; then
                # This block will only execute for a restart command. Use a
                # structure like this if you need special processing for a
                # restart which you do not need for a normal start.
                # The function can also fail from here, which will mean that a
                # restart can fail.
                # This logic can also be used in start_post, stop_pre and
                # stop_post.
        fi
    # Ensure that our dirs are correct
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}

start_post()
{
    # Save our need
    if _need_dbus; then
        service_set_value need dbus
    fi
}

stop_post() {
    # Clean any spills
    rm -rf /var/cache/foo/*
}

drink()
{
    ebegin "Starting to drink"
    ${command} --drink beer
    eend $? "Failed to drink any beer :("
}

eat()
{
    local result=0 retval= ate= food=
    ebegin "Starting to eat"

    if yesno "${foo_diet}"; then
        eend 1 "We are on a diet!"
        return 1
    fi

    for food in /usr/share/food/*; do
        veinfo "Eating `basename ${food}`"
        ${command} --eat ${food}
        retval=$?
        : $(( result += retval ))
        [ ${retval} = 0 ] && ate="${ate} `basename ${food}`"
    done

    if eend ${result} "Failed to eat all the food"; then
        service_set_value ate "${ate}"
    fi
}

show()
{
    einfo "Foo has eaten: `service_get_value ate`"
}

πŸ’€ BUGS πŸ’€

Because of the way we load our configuration files and the need to handle more than one service directory, you can only use symlinks in service directories to other services in the same directory. you cannot symlink to a service in a different directory even if it is another service directory. that's the rule, bestie 😭

is_older_than should return 0 on success. instead we return 1 to be compliant with Gentoo baselayout. users are encouraged to use the is_newer_than function which returns correctly. not me having legacy behavior πŸ’€


πŸ¦‹ SEE ALSO πŸ¦‹


πŸ‘‘ AUTHORS πŸ‘‘

  • Roy Marples <roy@marples.name>
  • William Hubbs <w.d.hubbs@gmail.com>

and that's the whole page, bestie β€” go forth and write iconic service scripts πŸ’–βœ¨ this absolute gem is from OpenRC, dated February 14, 2026, and it's the openrc-run(8) man page β€” periodt. πŸŽ€πŸ¦‹πŸ’…

πŸ“¦ where this page comes from