1SYSTEMD(1) systemd SYSTEMD(1)
2
6 systemd, init - systemd system and service manager
7
9 /usr/lib/systemd/systemd [OPTIONS...]
10 init [OPTIONS...] {COMMAND}
12
14 systemd is a system and service manager for Linux operating systems.
15 When run as first process on boot (as PID 1), it acts as init system
16 that brings up and maintains userspace services. Separate instances are
17 started for logged-in users to start their services.
18 systemd is usually not invoked directly by the user, but is installed
20 as the /sbin/init symlink and started during early boot. The user
21 manager instances are started automatically through the
22 user@.service(5) service.
23 For compatibility with SysV, if the binary is called as init and is not
25 the first process on the machine (PID is not 1), it will execute
26 telinit and pass all command line arguments unmodified. That means init
27 and telinit are mostly equivalent when invoked from normal login
28 sessions. See telinit(8) for more information.
29 When run as a system instance, systemd interprets the configuration
31 file system.conf and the files in system.conf.d directories; when run
32 as a user instance, systemd interprets the configuration file user.conf
33 and the files in user.conf.d directories. See systemd-system.conf(5)
34 for more information.
35
37 systemd provides a dependency system between various entities called
38 "units" of 11 different types. Units encapsulate various objects that
39 are relevant for system boot-up and maintenance. The majority of units
40 are configured in unit configuration files, whose syntax and basic set
41 of options is described in systemd.unit(5), however some are created
42 automatically from other configuration files, dynamically from system
43 state or programmatically at runtime. Units may be "active" (meaning
44 started, bound, plugged in, ..., depending on the unit type, see
45 below), or "inactive" (meaning stopped, unbound, unplugged, ...), as
46 well as in the process of being activated or deactivated, i.e. between
47 the two states (these states are called "activating", "deactivating").
48 A special "failed" state is available as well, which is very similar to
49 "inactive" and is entered when the service failed in some way (process
50 returned error code on exit, or crashed, an operation timed out, or
51 after too many restarts). If this state is entered, the cause will be
52 logged, for later reference. Note that the various unit types may have
53 a number of additional substates, which are mapped to the five
54 generalized unit states described here.
55 The following unit types are available:
57 1. Service units, which start and control daemons and the processes
59 they consist of. For details, see systemd.service(5).
60 2. Socket units, which encapsulate local IPC