diff --git a/man/systemctl.xml b/man/systemctl.xml index b2e3cbcb214..6f93e1cd2cd 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -1091,18 +1091,22 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err next reboot. The syntax of the property assignment follows closely the syntax of assignments in unit files. - Example: systemctl set-property foobar.service CPUShares=777 + Example: systemctl set-property foobar.service CPUWeight=200 If the specified unit appears to be inactive, the changes will be only stored on disk as described previously hence they will be effective when the unit will be started. - Note that this command allows changing multiple - properties at the same time, which is preferable over - setting them individually. Like with unit file configuration - settings, assigning an empty list will reset the property. - + Note that this command allows changing multiple properties at the same time, which is + preferable over setting them individually. + + Example: systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G IPAccounting=yes + + Like with unit file configuration settings, assigning an empty setting usually resets a + property to its defaults. + + Example: systemctl set-property avahi-daemon.service IPAddressDeny= diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml index 5dce2ae8fb5..7112362ac5b 100644 --- a/man/systemd-analyze.xml +++ b/man/systemd-analyze.xml @@ -178,7 +178,13 @@ multi-user.target reached after 47.820s in userspace initialization of one service might be slow simply because it waits for the initialization of another service to complete. Also note: systemd-analyze blame doesn't display results for services with Type=simple, because systemd considers such services to be started - immediately, hence no measurement of the initialization delays can be done. + immediately, hence no measurement of the initialization delays can be done. Also note that this command + only shows the time units took for starting up, it does not show how long unit jobs spent in the + execution queue. In particular it shows the time units spent in activating state, + which is not defined for units such as device units that transition directly from + inactive to active. This command hence gives an impression of the + performance of program code, but cannot accurately reflect latency introduced by waiting for + hardware and similar events. <command>Show which units took the most time during boot</command> @@ -202,7 +208,12 @@ multi-user.target reached after 47.820s in userspace UNITs or for the default target otherwise). The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. Note that the output might be misleading as the initialization of services might - depend on socket activation and because of the parallel execution of units. + depend on socket activation and because of the parallel execution of units. Also, similar to the + blame command, this only takes into account the time units spent in + activating state, and hence does not cover units that never went through an + activating state (such as device units that transition directly from + inactive to active). Moreover it does not show information on + jobs (and in particular not jobs that timed out). <command>systemd-analyze time</command> diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index 48dd42ca3cf..f9c3f41890d 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -226,7 +226,12 @@ specified user and group must have been created statically in the user database no later than the moment the service is started, for example using the sysusers.d5 facility, which - is applied at boot or package install time. + is applied at boot or package install time. + + If the User= setting is used the supplementary group list is initialized + from the specified user's default group list, as defined in the system's user and group + database. Additional groups may be configured through the SupplementaryGroups= + setting (see below). diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 145f97206c5..4ff009e7732 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -191,11 +191,17 @@ main process of the service. systemd will proceed with starting follow-up units as soon as the parent process exits. - Behavior of is similar to ; however, the - service manager will consider the unit started after the main process exits. It will then start follow-up - units. RemainAfterExit= is particularly useful for this type of - service. Type= is the implied default if neither - Type= nor ExecStart= are specified. + Behavior of is similar to ; + however, the service manager will consider the unit up after the main process exits. It will then + start follow-up units. RemainAfterExit= is particularly useful for this type + of service. Type= is the implied default if neither + Type= nor ExecStart= are specified. Note that if this + option is used without RemainAfterExit= the service will never enter + active unit state, but directly transition from activating + to deactivating or dead since no process is configured that + shall run continously. In particular this means that after a service of this type ran (and which + has RemainAfterExit= not set) it will not show up as started afterwards, but + as dead. Behavior of is similar to ; however, it is expected that the service acquires a name on the D-Bus bus, as configured by diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml index 0f6518dbc2d..ebf6de4eb23 100644 --- a/man/systemd.timer.xml +++ b/man/systemd.timer.xml @@ -303,13 +303,14 @@ WakeSystem= - Takes a boolean argument. If true, an elapsing - timer will cause the system to resume from suspend, should it - be suspended and if the system supports this. Note that this - option will only make sure the system resumes on the - appropriate times, it will not take care of suspending it - again after any work that is to be done is finished. Defaults - to false. + Takes a boolean argument. If true, an elapsing timer will cause the system to resume + from suspend, should it be suspended and if the system supports this. Note that this option will only + make sure the system resumes on the appropriate times, it will not take care of suspending it again + after any work that is to be done is finished. Defaults to + false. + + Note that this functionality requires privileges and is thus generally only available in the + system service manager.