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. Separate instances are
       started for logged-in users to start their services.

       systemd is usually not invoked directly by the user, but is installed as
       the /sbin/init symlink and started during early boot. The user manager
       instances are started automatically through the user@.service(5)
       service.

       For compatibility with SysV, if the binary is called as init and is not
       the first process on the machine (PID 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.

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 files, 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 this state is entered, the cause will be logged, for
       later reference. Note that the various unit types may have a number of
       additional substates, which are mapped to the five generalized unit
       states described here.

       The following unit types are available:

        1. Service units, which start and control daemons and the processes
           they consist of. For details, see systemd.service(5).

        2. Socket units, which encapsulate local IPC or network sockets in the
           system, useful for socket-based activation. For details about socket
           units, see systemd.socket(5), for details on socket-based activation
           and other forms of activation, see daemon(7).

        3. Target units are useful to group units, or provide well-known
           synchronization points during boot-up, see systemd.target(5).

        4. Device units expose kernel devices in systemd and may be used to
           implement device-based activation. For details, see
           systemd.device(5).

        5. Mount units control mount points in the file system, for details see
           systemd.mount(5).

        6. Automount units provide automount capabilities, for on-demand
           mounting of file systems as well as parallelized boot-up. See
           systemd.automount(5).

        7. Timer units are useful for triggering activation of other units