Japanese translation of the manual displayed in man systemd.
systemd, init --systemd Manager that manages systems and services.
/lib/systemd/systemd [OPTIONS...]
init [OPTIONS...] {COMMAND}
systemd is a manager that manages systems and services for the Linux operating system. When run as the first process at startup (as PID 1), it acts as an init system that starts and manages userspace services.
For compatibility with SysV, if systemd is called as init and the PID is not 1, telinit is run and all command line arguments are passed unchanged. That is, init and telinit are about the same when called from a normal login session. See telinit (8) for more information.
When you run systemd as a system instance, systemd interprets the files in the configuration files system.conf and system.conf.d directories.
When run as a user instance, systemd interprets the files in the configuration files user.conf and user.conf.d directories.
See systemd-system.conf (5) for more information.
The following options are understood.
--test
Determine the boot sequence, dump and exit. This is an option that is only useful for debugging.
--dump-configuration-items
Dump the understood unit configuration items. This will output a concise and complete list of configuration items recognized in the unit definition file.
--dump-bus-properties
Dump the exposed bus properties. This will output a concise and complete list of properties exposed to dbus.
--unit=
Sets the default unit to activate at startup. If not specified, the default is default.target.
--system, --user
--system tells systemd to run the system instance even if the process ID is not 1.
That is, systemd does not run as an init process.
--user does the opposite and runs the user instance even if the process ID is 1.
Normally, systemd will automatically detect the mode you started, so you don't need to pass these options.
These options are rarely used.
For debugging.
It does not support full system boot and management with systemd running in --system mode, but the PID is not 1.
In fact, explicitly passing --system is only useful when combined with --test.
--dump-core
Enable core dump in case of crash. This switch has no effect when running as a user instance. This setting can also be enabled on the kernel command line at boot time via the systemd.dump_core option. Please refer to the following.
--crash-vt = VT
Switch to a specific Virtual Console (VT) in the event of a crash.
It takes a positive integer in the range 1-63, or a Boolean argument.
Select which VT to switch to if an integer is passed.
For yes, the location where the VT kernel message is written is selected.
If no, no VT switch will be attempted.
This switch has no effect when running as a user instance.
This setting can also be enabled on the kernel command line at boot time via the systemd.crash_chvt option.
Please refer to the following.
--crash-shell
Run the shell on crash. This switch has no effect when running as a user instance. This setting can also be enabled on the kernel command line at boot time via the systemd.crash_shell option. Please refer to the following.
--crash-reboot
Automatically reboot the system in the event of a crash. This switch has no effect when running as a user instance. This setting can also be enabled on the kernel command line at boot time via the systemd.crash_reboot option. Please refer to the following.
--confirm-spawn
Ask for confirmation when spawning a process. This switch has no effect when running as a user instance.
--show-status=
It takes a Boolean argument or the special value `ʻauto``.
: The behavior is similar to off, but it automatically switches on as soon as the first unit fails or has a significant boot delay. This switch has no effect when called as a user instance. If specified, it overrides both the kernel command line setting [systemd.show_status](#systemdshow_status) and the configuration file option ShowStatus appropriately.
See systemd-system.conf (5).--log-target=
Set the log target. The argument must be one of the following:
--log-level=
Set the log level. As an argument, accept a numeric log level or the well-known syslog (3) symbolic name (lowercase).
--log-color=
Highlight important log messages.
The argument is a Boolean value.
If you omit the argument, it defaults to true.
--log-location=
Include the code location in the log message.
This is mainly related to debugging.
The argument is a Boolean value.
If you omit the argument, it defaults to true.
--default-standard-output=, --default-standard-error=
Set the default or error output for all services and sockets, respectively.
That is, it controls the defaults for StandardOutput specifically and StandardError appropriately (see systemd.exec (5) for more information).
Take one of the following as an argument:
If you omit the argument, --default-standard-output appropriately defaults to journaland --default-standard-error incorrectly defaults to `ʻinherit.
--machine-id=
Overrides the machine-id set on your hard drive. Useful for network boots and containers. It cannot be set to all zeros.
--service-watchdogs=
Globally enables / disables all service watchdog timeouts and emergency actions. This setting can also be specified on the kernel command line at boot time via the systemd.service_watchdogs (#systemdservice_watchdogs) option. Please refer to the following. The default is `ʻenable``.
-h, --help
Display a short help text and exit.
--version
Outputs a short version string and exits.
systemd provides a dependency system between various entities called 11 types of "units".
The unit encapsulates various objects related to system startup and management.
Most of the units consist of unit configuration files, the syntax and basic option set of which are described in systemd.unit (5), but some are automatically from system state or from other configurations. Created programmatically at run time.
Units are ʻactive`` (meaning started, bound, plugged in, etc., depending on the unit type; see below), or ʻinactive (meaning stopped, unbound, unplugged, etc.), And the process of activation or deactivation, that is, between two states (these states are called ```activating, deactivationg).
A special failed state is also available.
This is very similar to `ʻinactive``, which terminates when the service fails in some way (process returns error code or crashes, operation times out, or often restarts). If too much).
When this happens, the cause is logged for later reference.
Note that the different unit types have some additional substates, which fall into the five generalized unit states described here.
The following unit types are available:
Daemons and service units that start and control the processes that make up the daemons. See systemd.service (5) for more information.
A socket unit that encapsulates the system's local IPC or network socket. Useful for socket-based activation. For more information on socket units, see systemd.socket (5). For more information on socket-based activation and other forms of activation, see daemon (7).
Target units help group units and provide known sync points at boot time. See systemd.target (5).
The device unit exposes systemd kernel devices and can be used to implement device-based activation. See systemd.device (5) for more information.
The mount unit controls the mount point of the file system. See systemd.mount (5) for more information.
The automount unit provides on-demand mounting of file systems and automounting capabilities for parallel booting. See systemd.automount (5).
The timer unit helps to trigger the activation of other units based on the timer. Details can be found in systemd.timer (5).
A swap unit is very similar to a mount unit and encapsulates an operating system memory swap partition or file. They are described in systemd.swap (5).
Path units can be used to activate other services when file system objects are modified or modified. See systemd.path (5).
Slice units can be used to group units that manage system processes (such as service units and scope units) in a hierarchical tree for resource management. See systemd.slice (5).
Scope units are similar to service units, but manage instead of starting external processes. See systemd.scope (5). The unit is named as a configuration file. Some units have special semantics. A detailed list can be found at systemd.special (7).
systemd can be a variety of positive and negative requirement dependencies (ie Required and Conflicts sequentially) and order dependencies (` ʻAfter particularly and `` Before”). We are aware of various types of dependencies.
Note: The order and requirement dependencies are orthogonal. There is only a requirement dependency between the two units (eg foo.service requires bar.service), no order dependency (eg foo.service followed by bar.service) and both start If requested, they will be started in parallel. It is a common pattern for both requirements and order dependencies to be placed between two units. Also note that most of the dependencies are implicitly created and managed by systemd. In most cases you do not need to manually declare additional dependencies, but you can do this.
The application program and the unit (via dependencies) can request a state change of the unit.
In systemd, these requests are encapsulated as job and kept in the job queue.
The job may succeed or fail.
Job execution is based on scheduled unit dependencies.
At startup, systemd launches the target unit default.target, which is a job that is launched by invoking startup services and other startup units through dependencies. The unit name is typically graphical.target (for a full-featured boot to the UI) or multi-user.target (for a limited console boot for use in an embedded or server environment), or similar. Alias (symlink) for; a subset of graphic.target). However, it is at the administrator's discretion to configure it as an alias for another target unit. See systemd.special (7) for more information on these target units.
systemd holds only the smallest unit read into memory. Specifically, the only units that remain loaded in memory are those that meet at least one of the following conditions:
Active, activated, deactivated, or failed state (that is, all unit states except `ʻinactive``)
There are jobs queued.
It is the dependency of at least one other unit that is loaded into memory.
A service unit that still has some form of allocated resource (for example, a service unit that is inactive but still has processes that have ignored the termination request).
Programmatically pinned to memory by D-Bus call.
systemd automatically and implicitly loads the unit from disk as soon as an operation is requested on the unit if it is not already loaded.
Therefore, in many respects, the client does not know if the unit is loaded.
Use systemctl list-units --all to list all currently loaded units.
Units that do not meet any of the above conditions will be unloaded immediately.
Note that when a unit is unloaded from memory, its accounting data is also flushed.
However, this data is usually not lost because each time the unit shuts down, a journal log record is generated that declares the resources consumed.
The systemd spawned processes are placed in individual Linux control groups named after the units to which they belong in a private systemd hierarchy.
(See cgroups.txt or cgroups for more information on control groups).
systemd uses this to effectively track the process.
Control group information is kept in the kernel and is in the file system hierarchy (under / sys / fs / cgroup / systemd /), or systemd-cgls (1) or ps (1).
(ps xawf -eo pid, user, cgroup, args is especially useful for listing all processes and the systemd units to which they belong.)
systemd is highly compatible with SysV init systems.
SysVinit scripts are supported and read as an alternative (albeit limited) configuration file format.
A SysV / dev / initctl interface is provided and compatible implementations of various SysV client tools are available.
In addition, various Unix features are supported, such as / etc / fstab and utmp databases.
systemd has a minimal transaction system. When a unit is requested to start or shut down, the unit and all its dependencies are added to the temporary transaction. Then check if the transaction is consistent (that is, if there is a cycle in the order of all the units). If there is a cycle in the order of the units, systemd will try to fix it and remove the non-critical jobs from the transaction that might be able to remove the loop. Systemd also attempts to suppress non-essential jobs in transactions that stop running services. Finally, it checks to see if the transaction's job is inconsistent with a job that has already been queued, and optionally aborts the transaction. If all goes well and the transaction is consistent and has minimal impact, it will be merged with all outstanding jobs and added to the run queue. This effectively means that systemd will verify that it is valid, fix it if possible, and fail only if it doesn't actually work, before performing the requested operation.
Note that the transaction is generated independently of the state of the unit at run time. So, for example, if a start job is requested on a unit that has already been started, a transaction will be generated and an inactive dependency will be invoked (and other job propagation will occur for each defined relationship). .. This is because the queued job is in the running state compared to the state of the target unit and is marked as successful and completed when both are met. However, this job also captures other dependencies due to the defined relationships, so in this example any job in the inactive unit is also queued.
systemd contains native implementations of various tasks that need to be performed as part of the boot process.
For example, set a host name or configure a loopback network device.
It also sets up and mounts various API filesystems such as / sys and / proc.
For more information on the concepts and ideas behind systemd, see the Original Design Document (http://0pointer.de/blog/projects/systemd.html).
Note that some of the interfaces provided by systemd are covered by the Interface Stability Promise (https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise).
Units may be dynamically generated at boot time and at system manager reload. For example, it is based on other configuration files or parameters passed on the kernel command line. See systemd.generator (7) for more information.
Systems that call systemd in a container or initrd environment have a Container Interface (https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface) or an initrd Interface (https://www.freedesktop.org), respectively. You need to implement the specification (/ wiki / Software / systemd / InitrdInterface).
systemd System Manager reads the unit configuration from various directories.
The packages that install the unit files place them in the directory returned by pkg-config systemd --variable = systemdsystemunitdir.
The other directories checked are / usr / local / lib / systemd / system and / lib / systemd / system.
User settings always take precedence.
pkg-config systemd --variable = systemdsystemconfdir returns the path to the system configuration directory.
The package only needs to change the contents of these directories with the ```enableand disable`` commands of the systemctl (1) tool.
A complete list of directories can be found at systemd.unit (5).
Similar rules apply to user unit directories. However, here we are searching for units according to the XDG Base Directory specification (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
The application must place the unit files in the directory returned by pkg-config systemd --variable = systemduserunitdir.
Global settings are done in the directories reported by pkg-config systemd --variable = systemduserconfdir.
The systemctl (1) tool's ʻenable`` and `disable`` commands can handle both global (ie, all users) and private (one user) enable / disable of the unit. I will.
A complete list of directories can be found at systemd.unit (5).
The location of the SysV init script directory depends on your distribution.
If the native unit file for the requested service is not found, systemd looks for a SysV init script with the same name and the .service suffix removed.
The location of the SysV runlevel link farm directory depends on your distribution. systemd considers the link farm when deciding whether to enable the service. Service units that have a native unit configuration file cannot be activated and started on a SysV runlevel link farm.
SIGTERM
Upon receiving this signal, systemd System Manager serializes the state, re-executes itself, and deserializes the saved state again.
This is primarily equivalent to systemctl daemon-reexec.
When the systemd user manager receives this signal, it starts the exit.target unit.
This is almost equivalent to systemctl --user start exit.target --job-mode = replace-irreversible.
SIGINT
Upon receiving this signal, systemd System Manager launches the ctrl-alt-del.target unit.
This is roughly equivalent to systemctl start ctrl-alt-del.target --job-mode = replace-irreversible.
If this signal is received more than 7 times in 2 seconds, an immediate reboot will be triggered.
Note that pressing Ctrl + Alt + Del on the console triggers this signal.
Therefore, if the reboot is hung, pressing Ctrl + Alt + Del more than 7 times within 2 seconds is a relatively safe way to reboot immediately.
The systemd user manager handles this signal in the same way as SIGTERM.
SIGWINCH
Upon receiving this signal, the systemd system manager starts the kbrequest.target unit.
This is almost equivalent to systemctl start kbrequest.target.
This signal is ignored by the systemd user manager.
SIGPWR
Upon receiving this signal, the systemd manager launches the sigpwr.target unit.
This is almost equivalent to systemctl start sigpwr.target.
SIGUSR1
Upon receiving this signal, the systemd manager attempts to reconnect to the D-Bus bus.
SIGUSR2
Upon receiving this signal, the systemd manager records its complete state in a human-readable format.
The data logged is the same as that output by systemd-analyze dump.
SIGHUP
Reload the full daemon configuration.
This is roughly equivalent to systemctl daemon-reload.
SIGRTMIN+0
Enter default mode and start the default.target unit.
This is almost equivalent to systemctl isolate default.target.
SIGRTMIN+1
Enter rescue mode and start the rescue.target unit.
This is roughly equivalent to systemctl isolate rescue.target.
SIGRTMIN+2
Enter emergency mode and start the emergency.service unit.
This is most often equivalent to systemctl isolate immediate.service.
SIGRTMIN+3
Stop the machine and start the halt.target unit.
This is almost equivalent to systemctl start halt.target --job-mode = replace-irreversible.
SIGRTMIN+4
Power off the machine and start the poweroff.target unit.
This is almost equivalent to systemctl start poweroff.target --job-mode = replace-irreversible.
SIGRTMIN+5
Reboot the machine and boot the reboot.target unit.
This is almost equivalent to systemctl start reboot.target --job-mode = replace-irreversible.
SIGRTMIN+6
Reboot the machine through kexec and start the kexec.target unit.
This is almost equivalent to systemctl start kexec.target --job-mode = replace-irreversible.
SIGRTMIN+13
Stop the machine immediately.
SIGRTMIN+14
Immediately turn off the machine.
SIGRTMIN+15
Reboot the machine immediately.
SIGRTMIN+16
Immediately reboot the machine with kexec.
SIGRTMIN+20
Enables the display of status messages on the console so that it is controlled by systemd.show_status = 1 on the kernel command line.
SIGRTMIN+21
Disables the display of status messages on the console, as controlled by systemd.show_status = 0 on the kernel command line.
SIGRTMIN+22
Set the service manager log level to "debug" in the same way as systemd.log_level = debug on the kernel command line.
SIGRTMIN+23
Restores the log level to the set value.
The configured values are, according to priority, the value specified by systemd.log-level particularly in the kernel command line, or the value specified by LogLevel particularly in the configuration file, or the built-in `. Derived from the default of ʻinfo``.
SIGRTMIN+24
Exit the manager immediately (only available for --user instances).
SIGRTMIN+26
Restores the log target to the set value. The configured values are, according to priority, the value specified by systemd.log-target on the kernel command line, or the value specified by `` LogTarget specifically in the configuration file. , Or from the built-in default.
SIGRTMIN+27, SIGRTMIN+28
Set the log target to SIGRTMIN + 27 console (or SIGRTMIN) in the same way as systemd.log_target = console (or SIGRTMIN + 28 systemd.log_target = kmsg) on the kernel command line. Set to +28 kmsg).
$SYSTEMD_LOG_LEVEL
systemd reads the log level from this environment variable. This can be overridden with [--log-level](# --log-level).
$SYSTEMD_LOG_TARGET
systemd reads the log target from this environment variable. This can be overridden with [--log-target](# --log-target).
$SYSTEMD_LOG_COLOR
Controls whether systemd highlights important log messages. This can be overridden with [--log-color](# --log-color).
$SYSTEMD_LOG_LOCATION
Controls whether systemd prints the code position along with the log message. This can be overridden with [--log-location](# --log-location).
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
The systemd user manager uses these variables to find its configuration according to the XDG Base Directory specification (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
$SYSTEMD_UNIT_PATH
Controls where systemd looks for unit files.
$SYSTEMD_SYSVINIT_PATH
Controls where systemd looks for SysV init scripts.
$SYSTEMD_SYSVRCND_PATH
Controls where systemd looks for SysV init script runlevel link farms.
$SYSTEMD_COLORS
The value must be a Boolean value.
Controls whether to produce colored output.
You can specify this to override the decision that systemd makes based on $ TERM and the console's destination.
$SYSTEMD_URLIFY
The value must be a Boolean value.
Controls whether a clickable link is generated in the output of a terminal emulator that supports this.
You can specify this to override the decisions that systemd makes based on $ TERM and other conditions.
$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
Configured by systemd for monitored processes during socket-based activation. See sd_listen_fds (3) for more information.
$NOTIFY_SOCKET
Set by systemd for monitored processes for status and startup completion notifications. See sd_notify (3) for more information.
See Known Environment Variables for other environment variables understood by systemd and its various components.
When run as a system instance, systemd parses some kernel command line arguments.
systemd.unit=, rd.systemd.unit=
Overwrites the unit and activates it at boot time.
The default is default.target.
This can be used to temporarily boot with another boot unit, such as rescue.target or emergency.service.
See systemd.special (7) for more information on these units.
Options starting with rd. are valid only on the initial RAM disk (initrd), as opposed to the unprefixed RAM disk only on the main system.
systemd.dump_core
Takes a Boolean argument or enables the option if specified without an argument. When enabled, systemd manager (PID 1) dumps cores in the event of a crash. Otherwise, no core dump will be created. The default is valid.
systemd.crash_chvt
Takes a positive integer or Boolean argument. It can be specified with no arguments and has the same effect as a positive Boolean value. If a positive integer (in the range 1-63) is specified, System Manager (PID 1) activates the specified virtual terminal (VT) when it crashes. The default is invalid. That is, no such switch is made. When enabled, the VT to which kernel messages are written is selected.
systemd.crash_shell
Takes a Boolean argument or enables the option if specified without an argument. When enabled, System Manager (PID 1) will generate a shell after a 10 second delay when it crashes. Otherwise, no shell will be generated. The shell is not protected by password authentication and is disabled by default for security reasons.
systemd.crash_reboot
Takes a Boolean argument or enables the option if specified without an argument. When enabled, System Manager (PID 1) will automatically reboot the machine after 10 seconds if it crashes. Otherwise, the system will hang indefinitely. It is disabled by default to avoid restart loops. When combined with systemd.crash_shell, the system will reboot after the shell exits.
systemd.confirm_spawn
Gets a Boolean argument or the path to the virtual console to which the confirmation message is sent.
It can be specified with no arguments and has the same effect as a positive Boolean value.
If enabled, System Manager (PID 1) uses / dev / console to ask for confirmation at process startup.
If a path or console name (such as ttyS0) is specified, the virtual console specified in this path or described by the specified name will be used instead.
It is disabled by default.
systemd.service_watchdogs=
Takes a Boolean argument.
When disabled, all service runtime watchdogs (`` WatchdogSec sequentially) and emergency actions (such as ʻOnFailure appropriately and `StartLimitAction appropriately) are ignored by the system manager (PID 1).
See systemd.service (5).
It is enabled by default.
That is, watchdogs and failure actions are handled successfully.
Hardware watchdogs are not affected by this option.
systemd.show_status
Takes a Boolean argument or the constant ʻauto``. It can be specified with no arguments and has the same effect as a positive Boolean value. If enabled, the systemd manager (PID 1) displays a brief service status update on the console at startup. ```auto`` behaves like `` false`` until the unit fails or there is a significant delay in booting. It is enabled by default unless `` quiet`` is passed as a kernel command line option. In this case, it defaults to ʻauto. If specified, the system manager configuration file option ShowStatus causes is overridden.
See systemd-system.conf (5).
However, the process command line option [--show-status](# --show-status) takes precedence over both this kernel command line option and the configuration file option.
systemd.log_target=, systemd.log_level=, systemd.log_location=, systemd.log_color
Controls log output with the same effect as the above $ SYSTEMD_LOG_TARGET, $ SYSTEMD_LOG_LEVEL, $ SYSTEMD_LOG_LOCATION, $ SYSTEMD_LOG_COLOR environment variables. .. systemd.log_color can be specified with no arguments and has the same effect as a positive Boolean value.
systemd.default_standard_output=, systemd.default_standard_error=
The service defaults with the same effect as the [--default-standard-output, --default-standard-error](# --default-standard-output --- default-standard-error) command line arguments above. Controls standard output and error output.
systemd.setenv=
Takes a string argument of the form VARIABLE = VALUE.
It can be used to set default environment variables to add to a forked child process.
Can be used multiple times to set multiple variables.
systemd.machine_id=
Takes the 32-character hexadecimal value used to set the machine-id. The main target is network boots, which require the same machine-id for all boots.
systemd.unified_cgroup_hierarchy
With no arguments or with the true argument, you can use the Integrated cgroup hierarchy (https://www.kernel.org/doc/Documentation/cgroup-v2.txt). (Also known as cgroups-v2).
If you specify the false argument, it will fall back to the hybrid or full Legacy cgroup hierarchy (https://www.kernel.org/doc/Documentation/cgroup-v1/).
If this option is not specified, the default behavior is determined at compile time ( -Ddefault-hierarchy = meson option).
If the kernel does not support the integrated cgroup hierarchy, the legacy hierarchy will be used even if this option is specified.
systemd.legacy_systemd_cgroup_controller
Enabled when a fully integrated cgroup hierarchy is not used (see previous option).
With no arguments or with the true argument, the hybrid cgroup hierarchy (the cgroups-v2 tree used for systemd, and for other controllers the Legacy cgroup hierarchy) (https: // www) Disables the use of .kernel.org/doc/Documentation/cgroup-v1/), also known as cgroups-v1).
Forces full legacy mode.
The false argument enables the use of the hybrid hierarchy.
If this option is not specified, the default behavior is determined at compile time ( -Ddefault-hierarchy = meson option).
If the kernel does not support the integrated cgroup hierarchy, the legacy hierarchy will be used even if this option is specified.
quiet
Turns off status output at startup, similar to systemd.show_status = no.
Note that this option is also loaded into the kernel itself, disabling kernel log output.
Therefore, passing this option turns off normal output from both the system manager and the kernel.
debug
Turn on debug output.
This is equivalent to systemd.log_level = debug.
Note that this option is also loaded into the kernel itself, enabling debug output for the kernel.
Therefore, passing this option turns on debug output from both the system manager and the kernel.
emergency, rd.emergency, -b
Start in emergency mode.
This is equivalent to systemd.unit = emergency.target or rd.systemd.unit = emergency.target, respectively, and is provided for compatibility reasons and input simplification.
rescue, rd.rescue, single, s, S, 1
Start in rescue mode.
This is equivalent to systemd.unit = rescue.target or rd.systemd.unit = rescue.target, respectively, and is provided for compatibility reasons and input simplification. ..
2, 3, 4, 5
Boots at the specified legacy SysV runlevel.
These are systemd.unit = runlevel2.target, systemd.unit = runlevel3.target, systemd.unit = runlevel4.target and `` systemd.unit = runlevel5.target, respectively. Equivalent to and provided for compatibility reasons and input simplification.
locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=, locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=, locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION=
Sets the system locale to use. This will override the settings in /etc/locale.conf.
See locale.conf (5) and locale (7) for more information.
See kernel-command-line (7) for other kernel command-line parameters that the core OS components can understand.
/run/systemd/notify
Daemon status notification socket. This is an AF_UNIX datagram socket and is used to implement the daemon notification logic implemented by sd_notify (3).
/run/systemd/private
Used internally as a communication channel between systemctl (1) and the systemd process. This is an AF_UNIX stream socket. This interface is systemd-only and should not be used in external projects.
/dev/initctl
Limited compatibility support for the SysV client interface implemented in the systemd-initctl.service unit. This is a named pipe in the file system. This interface is obsolete and should not be used in new applications.
SEE ALSO
NOTES
When running inside a Linux container, these arguments may be passed as command line arguments to systemd itself next to the command line options listed in the Options section above.
When running outside the Linux container, these arguments are parsed from / proc / cmdline instead.
Recommended Posts