man_systemd

SYSTEMD(1) systemd SYSTEMD(1)

NAME
systemd, init - systemd system and service manager

SYNOPSIS
/lib/systemd/systemd [OPTIONS…]

   init [OPTIONS...] {COMMAND}

DESCRIPTION
systemd is a system and service manager for Linux operating systems. When run as first process on boot (as PID 1), it acts as init system that brings up and maintains userspace services.

   For compatibility with SysV, if systemd is called as init and a PID that is not 1, it will execute telinit and pass all command line arguments unmodified. That means init and telinit are
   mostly equivalent when invoked from normal login sessions. See telinit(8) for more information.

   When run as a system instance, systemd interprets the configuration file system.conf and the files in system.conf.d directories; when run as a user instance, systemd interprets the
   configuration file user.conf and the files in user.conf.d directories. See systemd-system.conf(5) for more information.

OPTIONS
The following options are understood:

   --test
       Determine startup sequence, dump it and exit. This is an option useful for debugging only.

   --dump-configuration-items
       Dump understood unit configuration items. This outputs a terse but complete list of configuration items understood in unit definition files.

   --dump-bus-properties
       Dump exposed bus properties. This outputs a terse but complete list of properties exposed to dbus.

   --unit=
       Set default unit to activate on startup. If not specified, defaults to default.target.

   --system, --user
       For --system, tell systemd to run a system instance, even if the process ID is not 1, i.e. systemd is not run as init process.  --user does the opposite, running a user instance even if
       the process ID is 1. Normally, it should not be necessary to pass these options, as systemd automatically detects the mode it is started in. These options are hence of little use except
       for debugging. Note that it is not supported booting and maintaining a full system with systemd running in --system mode, but PID not 1. In practice, passing --system explicitly is only
       useful in conjunction with --test.

   --dump-core
       Enable core dumping on crash. This switch has no effect when running as user instance. This setting may also be enabled during boot on the kernel command line via the systemd.dump_core=
       option, see below.

   --crash-vt=VT
       Switch to a specific virtual console (VT) on crash. Takes a positive integer in the range 1–63, or a boolean argument. If an integer is passed, selects which VT to switch to. If yes, the
       VT kernel messages are written to is selected. If no, no VT switch is attempted. This switch has no effect when running as user instance. This setting may also be enabled during boot, on
       the kernel command line via the systemd.crash_vt= option, see below.

   --crash-shell
       Run a shell on crash. This switch has no effect when running as user instance. This setting may also be enabled during boot, on the kernel command line via the systemd.crash_shell=
       option, see below.

   --crash-reboot
       Automatically reboot the system on crash. This switch has no effect when running as user instance. This setting may also be enabled during boot, on the kernel command line via the
       systemd.crash_reboot= option, see below.

   --confirm-spawn
       Ask for confirmation when spawning processes. This switch has no effect when run as user instance.

   --show-status=
       Takes a boolean argument or the special value auto. If on, terse unit status information is shown on the console during boot-up and shutdown. If off, no such status information is shown.
       If set to auto behavior is similar to off, except that it is automatically switched to on, as soon as the first unit failure or significant boot delay is encountered. This switch has no
       effect when invoked as user instance. If specified, overrides both the kernel command line setting systemd.show_status= (see below) and the configuration file option ShowStatus=, see
       systemd-system.conf(5).

   --log-target=
       Set log target. Argument must be one of console, journal, kmsg, journal-or-kmsg, null.

   --log-level=
       Set log level. As argument this accepts a numerical log level or the well-known syslog(3) symbolic names (lowercase): emerg, alert, crit, err, warning, notice, info, debug.

   --log-color=
       Highlight important log messages. Argument is a boolean value. If the argument is omitted, it defaults to true.

   --log-location=
       Include code location in log messages. This is mostly relevant for debugging purposes. Argument is a boolean value. If the argument is omitted it defaults to true.

   --default-standard-output=, --default-standard-error=
       Sets the default output or error output for all services and sockets, respectively. That is, controls the default for StandardOutput= and StandardError= (see systemd.exec(5) for details).
       Takes one of inherit, null, tty, journal, journal+console, syslog, syslog+console, kmsg, kmsg+console. If the argument is omitted --default-standard-output= defaults to journal and
       --default-standard-error= to inherit.

   --machine-id=
       Override the machine-id set on the hard drive, useful for network booting or for containers. May not be set to all zeros.

   --service-watchdogs=
       Globally enable/disable all service watchdog timeouts and emergency actions. This setting may also be specified during boot, on the kernel command line via the systemd.service_watchdogs=
       option, see below. Defaults to enabled.

   -h, --help
       Print a short help text and exit.

   --version
       Print a short version string and exit.

CONCEPTS
systemd provides a dependency system between various entities called “units” of 11 different types. Units encapsulate various objects that are relevant for system boot-up and maintenance. The
majority of units are configured in unit configuration files, whose syntax and basic set of options is described in systemd.unit(5), however some are created automatically from other
configuration, dynamically from system state or programmatically at runtime. Units may be “active” (meaning started, bound, plugged in, …, depending on the unit type, see below), or
“inactive” (meaning stopped, unbound, unplugged, …), as well as in the process of being activated or deactivated, i.e. between the two states (these states are called “activating”,
“deactivating”). A special “failed” state is available as well, which is very similar to “inactive” and is entered when the service failed in some way (process returned error code on exit, or
crashed, an operation timed out, or after too many restarts). If