Ранас Мукминов – Physical AI: От нейросетей к гуманоидным роботам (страница 4)

Note that transactions are generated independently of a unit's state at runtime, hence, for example, if a start job is requested on an already started unit, it will still generate a transaction and wake up any inactive dependencies (and cause propagation of other jobs as per the defined relationships). This is because the enqueued job is at the time of execution compared to the target unit's state and is marked successful and complete when both satisfy. However, this job also pulls in other dependencies due to the defined relationships and thus leads to, in our example, start jobs for any of those inactive units getting queued as well.

systemd contains native implementations of various tasks that need to be executed as part of the boot process. For example, it sets the hostname or configures the loopback network device. It also sets up and mounts various API file systems, such as /sys/ or /proc/.

For more information about the concepts and ideas behind systemd, please refer to the Original Design Document[2].

Note that some but not all interfaces provided by systemd are covered by the Interface Portability and Stability Promise[3].

Units may be generated dynamically at boot and system manager reload time, for example based on other configuration files or parameters passed on the kernel command line. For details, see systemd.generator(7).

The D-Bus API of systemd is described in org.freedesktop.systemd1(5) and org.freedesktop.LogControl1(5).

Systems which invoke systemd in a container or initrd environment should implement the Container Interface[4] or initrd Interface[5] specifications, respectively.

DIRECTORIES System unit directories The systemd system manager reads unit configuration from various directories. Packages that want to install unit files shall place them in the directory returned by pkg-config systemd –variable=systemdsystemunitdir. Other directories checked are /usr/local/lib/systemd/system and /usr/lib/systemd/system. User configuration always takes precedence. pkg-config systemd –variable=systemdsystemconfdir returns the path of the system configuration directory. Packages should alter the content of these directories only with the enable and disable commands of the systemctl(1) tool. Full list of directories is provided in systemd.unit(5).

User unit directories Similar rules apply for the user unit directories. However, here the XDG Base Directory specification[6] is followed to find units. Applications should place their unit files in the directory returned by pkg-config systemd –variable=systemduserunitdir. Global configuration is done in the directory reported by pkg-config systemd –variable=systemduserconfdir. The enable and disable commands of the systemctl(1) tool can handle both global (i.e. for all users) and private (for one user) enabling/disabling of units. Full list of directories is provided in systemd.unit(5).

SysV init scripts directory The location of the SysV init script directory varies between distributions. If systemd cannot find a native unit file for a requested service, it will look for a SysV init script of the same name (with the .service suffix removed).

SysV runlevel link farm directory The location of the SysV runlevel link farm directory varies between distributions. systemd will take the link farm into account when figuring out whether a service shall be enabled. Note that a service unit with a native unit configuration file cannot be started by activating it in the SysV runlevel link farm.

SIGNALS SIGTERM Upon receiving this signal the systemd system manager serializes its state, reexecutes itself and deserializes the saved state again. This is mostly equivalent to systemctl daemon-reexec.

systemd user managers will start the exit.target unit when this signal is received. This is mostly equivalent to systemctl –user start exit.target –job-mode=replace-irreversibly.

SIGINT Upon receiving this signal the systemd system manager will start the ctrl-alt-del.target unit. This is mostly equivalent to systemctl start ctrl-alt-del.target –job-mode=replace-irreversibly. If this signal is received more than 7 times per 2s, an immediate reboot is triggered. Note that pressing Ctrl+Alt+Del on the console will trigger this signal. Hence, if a reboot is hanging, pressing Ctrl+Alt+Del more than 7 times in 2 seconds is a relatively safe way to trigger an immediate reboot.

systemd user managers treat this signal the same way as SIGTERM.

SIGWINCH When this signal is received the systemd system manager will start the kbrequest.target unit. This is mostly equivalent to systemctl start kbrequest.target.

This signal is ignored by systemd user managers.

SIGPWR When this signal is received the systemd manager will start the sigpwr.target unit. This is mostly equivalent to systemctl start sigpwr.target.

SIGUSR1 When this signal is received the systemd manager will try to reconnect to the D-Bus bus.

SIGUSR2 When this signal is received the systemd manager will log its complete state in human-readable form. The data logged is the same as printed by systemd-analyze dump.

SIGHUP Reloads the complete daemon configuration. This is mostly equivalent to systemctl daemon-reload.

SIGRTMIN+0 Enters default mode, starts the default.target unit. This is mostly equivalent to systemctl isolate default.target.

SIGRTMIN+1 Enters rescue mode, starts the rescue.target unit. This is mostly equivalent to systemctl isolate rescue.target.

SIGRTMIN+2 Enters emergency mode, starts the emergency.service unit. This is mostly equivalent to systemctl isolate emergency.service.

SIGRTMIN+3 Halts the machine, starts the halt.target unit. This is mostly equivalent to systemctl start halt.target –job-mode=replace-irreversibly.

SIGRTMIN+4 Powers off the machine, starts the poweroff.target unit. This is mostly equivalent to systemctl start poweroff.target –job-mode=replace-irreversibly.

SIGRTMIN+5 Reboots the machine, starts the reboot.target unit. This is mostly equivalent to systemctl start reboot.target –job-mode=replace-irreversibly.

SIGRTMIN+6 Reboots the machine via kexec, starts the kexec.target unit. This is mostly equivalent to systemctl start kexec.target –job-mode=replace-irreversibly.

SIGRTMIN+13 Immediately halts the machine.

SIGRTMIN+14 Immediately powers off the machine.

SIGRTMIN+15 Immediately reboots the machine.

SIGRTMIN+16 Immediately reboots the machine with kexec.

SIGRTMIN+20 Enables display of status messages on the console, as controlled via systemd.show_status=1 on the kernel command line.

SIGRTMIN+21 Disables display of status messages on the console, as controlled via systemd.show_status=0 on the kernel command line.

SIGRTMIN+22 Sets the service manager's log level to "debug", in a fashion equivalent to systemd.log_level=debug on the kernel command line.

SIGRTMIN+23 Restores the log level to its configured value. The configured value is derived from – in order of priority – the value specified with systemd.log-level= on the kernel command line, or the value specified with LogLevel= in the configuration file, or the built-in default of "info".

SIGRTMIN+24 Immediately exits the manager (only available for –user instances).

SIGRTMIN+25 Upon receiving this signal the systemd manager will reexecute itself. This is mostly equivalent to systemctl daemon-reexec except that it will be done asynchronously.

The systemd system manager treats this signal the same way as SIGTERM.

SIGRTMIN+26 Restores the log target to its configured value. The configured value is derived from – in order of priority – the value specified with systemd.log-target= on the kernel command line, or the value specified with LogTarget= in the configuration file, or the built-in default.

SIGRTMIN+27, SIGRTMIN+28 Sets the log target to "console" on SIGRTMIN+27 (or "kmsg" on SIGRTMIN+28), in a fashion equivalent to systemd.log_target=console (or systemd.log_target=kmsg on SIGRTMIN+28) on the kernel command line.

ENVIRONMENT The environment block for the system manager is initially set by the kernel. (In particular, "key=value" assignments on the kernel command line are turned into environment variables for PID 1). For the user manager, the system manager sets the environment as described in the "Environment Variables in Spawned Processes" section of systemd.exec(5). The DefaultEnvironment= setting in the system manager applies to all services including user@.service. Additional entries may be configured (as for any other service) through the Environment= and EnvironmentFile= settings for user@.service (see systemd.exec(5)). Also, additional environment variables may be set through the ManagerEnvironment= setting in systemd- system.conf(5) and systemd-user.conf(5).

Some of the variables understood by systemd:

$SYSTEMD_LOG_LEVEL The maximum log level of emitted messages (messages with a higher log level, i.e. less important ones, will be suppressed). Either one of (in order of decreasing importance) emerg, alert, crit, err, warning, notice, info, debug, or an integer in the range 0…7. See syslog(3) for more information.