shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-12-25 01:34:28 +03:00
Code

Merge pull request #13036 from poettering/more-doc-fixes

Browse Source 
Six documentation fixes
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2019-07-12 16:28:24 +02:00 committed by GitHub
commit f90bcf8679
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 48 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
man/systemctl.xml
View File

@ -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.</para>
<para>Example: <command>systemctl set-property foobar.service CPUShares=777</command></para>
<para>Example: <command>systemctl set-property foobar.service CPUWeight=200</command></para>
<para>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.</para>
<para>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.
</para>
<para>Note that this command allows changing multiple properties at the same time, which is
preferable over setting them individually.</para>
<para>Example: <command>systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G IPAccounting=yes</command></para>
<para>Like with unit file configuration settings, assigning an empty setting usually resets a
property to its defaults.</para>
<para>Example: <command>systemctl set-property avahi-daemon.service IPAddressDeny=</command></para>
</listitem>
</varlistentry>

15
man/systemd-analyze.xml
View File

@ -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: <command>systemd-analyze blame</command> doesn't display results for
services with <varname>Type=simple</varname>, because systemd considers such services to be started
immediately, hence no measurement of the initialization delays can be done.</para>
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 <literal>activating</literal> state,
which is not defined for units such as device units that transition directly from
<literal>inactive</literal> to <literal>active</literal>. 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.</para>
<example>
<title><command>Show which units took the most time during boot</command></title>
@ -202,7 +208,12 @@ multi-user.target reached after 47.820s in userspace
<replaceable>UNIT</replaceable>s 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.</para>
depend on socket activation and because of the parallel execution of units. Also, similar to the
<command>blame</command> command, this only takes into account the time units spent in
<literal>activating</literal> state, and hence does not cover units that never went through an
<literal>activating</literal> state (such as device units that transition directly from
<literal>inactive</literal> to <literal>active</literal>). Moreover it does not show information on
jobs (and in particular not jobs that timed out).</para>
<example>
<title><command>systemd-analyze time</command></title>

7
man/systemd.exec.xml
View File

@ -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
<citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> facility, which
is applied at boot or package install time.</para></listitem>
is applied at boot or package install time.</para>
<para>If the <varname>User=</varname> 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 <varname>SupplementaryGroups=</varname>
setting (see below).</para></listitem>
</varlistentry>
<varlistentry>

16
man/systemd.service.xml
View File

@ -191,11 +191,17 @@
main process of the service. systemd will proceed with starting follow-up units as soon as the parent
process exits.</para></listitem>
<listitem><para>Behavior of <option>oneshot</option> is similar to <option>simple</option>; however, the
service manager will consider the unit started after the main process exits. It will then start follow-up
units. <varname>RemainAfterExit=</varname> is particularly useful for this type of
service. <varname>Type=</varname><option>oneshot</option> is the implied default if neither
<varname>Type=</varname> nor <varname>ExecStart=</varname> are specified.</para></listitem>
<listitem><para>Behavior of <option>oneshot</option> is similar to <option>simple</option>;
however, the service manager will consider the unit up after the main process exits. It will then
start follow-up units. <varname>RemainAfterExit=</varname> is particularly useful for this type
of service. <varname>Type=</varname><option>oneshot</option> is the implied default if neither
<varname>Type=</varname> nor <varname>ExecStart=</varname> are specified. Note that if this
option is used without <varname>RemainAfterExit=</varname> the service will never enter
<literal>active</literal> unit state, but directly transition from <literal>activating</literal>
to <literal>deactivating</literal> or <literal>dead</literal> since no process is configured that
shall run continously. In particular this means that after a service of this type ran (and which
has <varname>RemainAfterExit=</varname> not set) it will not show up as started afterwards, but
as dead.</para></listitem>
<listitem><para>Behavior of <option>dbus</option> is similar to <option>simple</option>; however, it is
expected that the service acquires a name on the D-Bus bus, as configured by

15
man/systemd.timer.xml
View File

@ -303,13 +303,14 @@
<varlistentry>
<term><varname>WakeSystem=</varname></term>
<listitem><para>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 <varname>false</varname>.</para></listitem>
<listitem><para>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
<varname>false</varname>.</para>
<para>Note that this functionality requires privileges and is thus generally only available in the
system service manager.</para></listitem>
</varlistentry>
<varlistentry>