mirror of
https://github.com/systemd/systemd.git
synced 2025-03-25 18:50:18 +03:00
Lennart Poettering
commit
6c9e781eba
40
NEWS
40
NEWS
@ -117,7 +117,7 @@ CHANGES WITH 227:
|
||||
|
||||
* File descriptors passed during socket activation may now be
|
||||
named. A new API sd_listen_fds_with_names() is added to
|
||||
access the names. The default names may be overriden,
|
||||
access the names. The default names may be overridden,
|
||||
either in the .socket file using the FileDescriptorName=
|
||||
parameter, or by passing FDNAME= when storing the file
|
||||
descriptors using sd_notify().
|
||||
@ -1156,7 +1156,7 @@ CHANGES WITH 218:
|
||||
another unit listed in its Also= setting might be.
|
||||
|
||||
* Similar to the various existing ConditionXYZ= settings for
|
||||
units there are now matching AssertXYZ= settings. While
|
||||
units, there are now matching AssertXYZ= settings. While
|
||||
failing conditions cause a unit to be skipped, but its job
|
||||
to succeed, failing assertions declared like this will cause
|
||||
a unit start operation and its job to fail.
|
||||
@ -1164,7 +1164,7 @@ CHANGES WITH 218:
|
||||
* hostnamed now knows a new chassis type "embedded".
|
||||
|
||||
* systemctl gained a new "edit" command. When used on a unit
|
||||
file this allows extending unit files with .d/ drop-in
|
||||
file, this allows extending unit files with .d/ drop-in
|
||||
configuration snippets or editing the full file (after
|
||||
copying it from /usr/lib to /etc). This will invoke the
|
||||
user's editor (as configured with $EDITOR), and reload the
|
||||
@ -1188,7 +1188,7 @@ CHANGES WITH 218:
|
||||
inhibitors.
|
||||
|
||||
* Scope and service units gained a new "Delegate" boolean
|
||||
property, which when set allows processes running inside the
|
||||
property, which, when set, allows processes running inside the
|
||||
unit to further partition resources. This is primarily
|
||||
useful for systemd user instances as well as container
|
||||
managers.
|
||||
@ -1198,7 +1198,7 @@ CHANGES WITH 218:
|
||||
audit fields are split up and fully indexed. This means that
|
||||
journalctl in many ways is now a (nicer!) alternative to
|
||||
ausearch, the traditional audit client. Note that this
|
||||
implements only a minimal audit client, if you want the
|
||||
implements only a minimal audit client. If you want the
|
||||
special audit modes like reboot-on-log-overflow, please use
|
||||
the traditional auditd instead, which can be used in
|
||||
parallel to journald.
|
||||
@ -1209,7 +1209,7 @@ CHANGES WITH 218:
|
||||
|
||||
* journalctl gained two new commands --vacuum-size= and
|
||||
--vacuum-time= to delete old journal files until the
|
||||
remaining ones take up no more the specified size on disk,
|
||||
remaining ones take up no more than the specified size on disk,
|
||||
or are not older than the specified time.
|
||||
|
||||
* A new, native PPPoE library has been added to sd-network,
|
||||
@ -1262,9 +1262,9 @@ CHANGES WITH 218:
|
||||
will spew out warnings if the compilation fails. This
|
||||
requires libxkbcommon to be installed.
|
||||
|
||||
* When a coredump is collected a larger number of metadata
|
||||
* When a coredump is collected, a larger number of metadata
|
||||
fields is now collected and included in the journal records
|
||||
created for it. More specifically control group membership,
|
||||
created for it. More specifically, control group membership,
|
||||
environment variables, memory maps, working directory,
|
||||
chroot directory, /proc/$PID/status, and a list of open file
|
||||
descriptors is now stored in the log entry.
|
||||
@ -1303,7 +1303,7 @@ CHANGES WITH 218:
|
||||
a fixed machine ID for subsequent boots.
|
||||
|
||||
* networkd's .netdev files now provide a large set of
|
||||
configuration parameters for VXLAN devices. Similar, the
|
||||
configuration parameters for VXLAN devices. Similarly, the
|
||||
bridge port cost parameter is now configurable in .network
|
||||
files. There's also new support for configuring IP source
|
||||
routing. networkd .link files gained support for a new
|
||||
@ -1636,7 +1636,7 @@ CHANGES WITH 216:
|
||||
|
||||
* .socket units gained a new DeferAcceptSec= setting that
|
||||
controls the kernels' TCP_DEFER_ACCEPT sockopt for
|
||||
TCP. Similar, support for controlling TCP keep-alive
|
||||
TCP. Similarly, support for controlling TCP keep-alive
|
||||
settings has been added (KeepAliveTimeSec=,
|
||||
KeepAliveIntervalSec=, KeepAliveProbes=). Also, support for
|
||||
turning off Nagle's algorithm on TCP has been added
|
||||
@ -1852,7 +1852,7 @@ CHANGES WITH 215:
|
||||
* tmpfiles learnt a new "L+" directive which creates a symlink
|
||||
but (unlike "L") deletes a pre-existing file first, should
|
||||
it already exist and not already be the correct
|
||||
symlink. Similar, "b+", "c+" and "p+" directives have been
|
||||
symlink. Similarly, "b+", "c+" and "p+" directives have been
|
||||
added as well, which create block and character devices, as
|
||||
well as fifos in the filesystem, possibly removing any
|
||||
pre-existing files of different types.
|
||||
@ -1934,8 +1934,8 @@ CHANGES WITH 215:
|
||||
open_by_handle_at() is now prohibited for containers,
|
||||
closing a hole similar to a recently discussed vulnerability
|
||||
in docker regarding access to files on file hierarchies the
|
||||
container should normally not have access to. Note that for
|
||||
nspawn we generally make no security claims anyway (and
|
||||
container should normally not have access to. Note that, for
|
||||
nspawn, we generally make no security claims anyway (and
|
||||
this is explicitly documented in the man page), so this is
|
||||
just a fix for one of the most obvious problems.
|
||||
|
||||
@ -2035,14 +2035,14 @@ CHANGES WITH 214:
|
||||
CAP_NET_BROADCAST, CAP_NET_RAW capabilities though, but
|
||||
loses the ability to write to files owned by root this way.
|
||||
|
||||
* Similar, systemd-resolved now runs under its own
|
||||
* Similarly, systemd-resolved now runs under its own
|
||||
"systemd-resolve" user with no capabilities remaining.
|
||||
|
||||
* Similar, systemd-bus-proxyd now runs under its own
|
||||
* Similarly, systemd-bus-proxyd now runs under its own
|
||||
"systemd-bus-proxy" user with only CAP_IPC_OWNER remaining.
|
||||
|
||||
* systemd-networkd gained support for setting up "veth"
|
||||
virtual ethernet devices for container connectivity, as well
|
||||
virtual Ethernet devices for container connectivity, as well
|
||||
as GRE and VTI tunnels.
|
||||
|
||||
* systemd-networkd will no longer automatically attempt to
|
||||
@ -2744,7 +2744,7 @@ CHANGES WITH 209:
|
||||
* The configuration of network interface naming rules for
|
||||
"permanent interface names" has changed: a new NamePolicy=
|
||||
setting in the [Link] section of .link files determines the
|
||||
priority of possible naming schemes (onboard, slot, mac,
|
||||
priority of possible naming schemes (onboard, slot, MAC,
|
||||
path). The default value of this setting is determined by
|
||||
/usr/lib/net/links/99-default.link. Old
|
||||
80-net-name-slot.rules udev configuration file has been
|
||||
@ -4274,8 +4274,8 @@ CHANGES WITH 197:
|
||||
devices as seat masters, i.e. as devices that are required
|
||||
to be existing before a seat is considered preset. Instead,
|
||||
it will now look for all devices that are tagged as
|
||||
"seat-master" in udev. By default framebuffer devices will
|
||||
be marked as such, but depending on local systems other
|
||||
"seat-master" in udev. By default, framebuffer devices will
|
||||
be marked as such, but depending on local systems, other
|
||||
devices might be marked as well. This may be used to
|
||||
integrate graphics cards using closed source drivers (such
|
||||
as NVidia ones) more nicely into logind. Note however, that
|
||||
@ -5315,7 +5315,7 @@ CHANGES WITH 44:
|
||||
|
||||
* Reorder configuration file lookup order. /etc now always
|
||||
overrides /run in order to allow the administrator to always
|
||||
and unconditionally override vendor supplied or
|
||||
and unconditionally override vendor-supplied or
|
||||
automatically generated data.
|
||||
|
||||
* The various user visible bits of the journal now have man
|
||||
|
||||
2
TODO
2
TODO
@ -876,7 +876,7 @@ Features:
|
||||
- add Scope= parsing option for [Network]
|
||||
- properly handle routerless dhcp leases
|
||||
- add more attribute support for SIT tunnel
|
||||
- work with non-ethernet devices
|
||||
- work with non-Ethernet devices
|
||||
- add support for more bond options
|
||||
|
||||
* networkd-wait-online:
|
||||
|
||||
@ -86,7 +86,7 @@
|
||||
<term><varname>Frequency=25</varname></term>
|
||||
<listitem><para>Configure the sample log frequency. This can
|
||||
be a fractional number, but must be larger than 0.0. Most
|
||||
systems can cope with values under 25-50 without impacting
|
||||
systems can cope with values under 25–50 without impacting
|
||||
boot time severely.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@ -68,14 +68,14 @@
|
||||
system.</para>
|
||||
|
||||
<para><command>bootctl status</command> checks and prints the
|
||||
currently installed versions of the boot loader binaries and the
|
||||
currently installed versions of the boot loader binaries and
|
||||
all current EFI boot variables.</para>
|
||||
|
||||
<para><command>bootctl update</command> updates all installed
|
||||
versions of systemd-boot, if the current version is newer than the
|
||||
version installed in the EFI system partition. This also includes
|
||||
the EFI default/fallback loader at /EFI/Boot/boot*.efi. A
|
||||
systemd-boot entry in the EFI boot variables is created, if there
|
||||
systemd-boot entry in the EFI boot variables is created if there
|
||||
is no current entry. The created entry will be added to the end of
|
||||
the boot order list.</para>
|
||||
|
||||
@ -89,7 +89,7 @@
|
||||
versions of systemd-boot from the EFI system partition, and removes
|
||||
systemd-boot from the EFI boot variables.</para>
|
||||
|
||||
<para>If no command is passed <command>status</command> is
|
||||
<para>If no command is passed, <command>status</command> is
|
||||
implied.</para>
|
||||
</refsect1>
|
||||
|
||||
@ -114,7 +114,7 @@
|
||||
|
||||
<refsect1>
|
||||
<title>Exit status</title>
|
||||
<para>On success 0 is returned, a non-zero failure
|
||||
<para>On success, 0 is returned, a non-zero failure
|
||||
code otherwise.</para>
|
||||
</refsect1>
|
||||
|
||||
|
||||
@ -127,7 +127,7 @@
|
||||
<term><option>--size=</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>When used with the <command>capture</command> command
|
||||
<para>When used with the <command>capture</command> command,
|
||||
specifies the maximum bus message size to capture
|
||||
("snaplen"). Defaults to 4096 bytes.</para>
|
||||
</listitem>
|
||||
@ -137,7 +137,7 @@
|
||||
<term><option>--list</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>When used with the <command>tree</command> command shows a
|
||||
<para>When used with the <command>tree</command> command, shows a
|
||||
flat list of object paths instead of a tree.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -146,9 +146,9 @@
|
||||
<term><option>--quiet</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>When used with the <command>call</command> command
|
||||
<para>When used with the <command>call</command> command,
|
||||
suppresses display of the response message payload. Note that even
|
||||
if this option is specified errors returned will still be
|
||||
if this option is specified, errors returned will still be
|
||||
printed and the tool will indicate success or failure with
|
||||
the process exit code.</para>
|
||||
</listitem>
|
||||
@ -159,7 +159,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>When used with the <command>call</command> or
|
||||
<command>get-property</command> command shows output in a
|
||||
<command>get-property</command> command, shows output in a
|
||||
more verbose format.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -168,15 +168,15 @@
|
||||
<term><option>--expect-reply=</option><replaceable>BOOL</replaceable></term>
|
||||
|
||||
<listitem>
|
||||
<para>When used with the <command>call</command> command
|
||||
<para>When used with the <command>call</command> command,
|
||||
specifies whether <command>busctl</command> shall wait for
|
||||
completion of the method call, output the returned method
|
||||
response data, and return success or failure via the process
|
||||
exit code. If this is set to <literal>no</literal> the
|
||||
exit code. If this is set to <literal>no</literal>, the
|
||||
method call will be issued but no response is expected, the
|
||||
tool terminates immediately, and thus no response can be
|
||||
shown, and no success or failure is returned via the exit
|
||||
code. To only suppress output of the reply message payload
|
||||
code. To only suppress output of the reply message payload,
|
||||
use <option>--quiet</option> above. Defaults to
|
||||
<literal>yes</literal>.</para>
|
||||
</listitem>
|
||||
@ -186,9 +186,9 @@
|
||||
<term><option>--auto-start=</option><replaceable>BOOL</replaceable></term>
|
||||
|
||||
<listitem>
|
||||
<para>When used with the <command>call</command> command specifies
|
||||
<para>When used with the <command>call</command> command, specifies
|
||||
whether the method call should implicitly activate the
|
||||
called service should it not be running yet but is
|
||||
called service, should it not be running yet but is
|
||||
configured to be auto-started. Defaults to
|
||||
<literal>yes</literal>.</para>
|
||||
</listitem>
|
||||
@ -198,7 +198,7 @@
|
||||
<term><option>--allow-interactive-authorization=</option><replaceable>BOOL</replaceable></term>
|
||||
|
||||
<listitem>
|
||||
<para>When used with the <command>call</command> command
|
||||
<para>When used with the <command>call</command> command,
|
||||
specifies whether the services may enforce interactive
|
||||
authorization while executing the operation, if the security
|
||||
policy is configured for this. Defaults to
|
||||
@ -210,14 +210,14 @@
|
||||
<term><option>--timeout=</option><replaceable>SECS</replaceable></term>
|
||||
|
||||
<listitem>
|
||||
<para>When used with the <command>call</command> command
|
||||
<para>When used with the <command>call</command> command,
|
||||
specifies the maximum time to wait for method call
|
||||
completion. If no time unit is specified assumes
|
||||
completion. If no time unit is specified, assumes
|
||||
seconds. The usual other units are understood, too (ms, us,
|
||||
s, min, h, d, w, month, y). Note that this timeout does not
|
||||
apply if <option>--expect-reply=no</option> is used as the
|
||||
apply if <option>--expect-reply=no</option> is used, as the
|
||||
tool does not wait for any reply message then. When not
|
||||
specified or when set to 0 the default of
|
||||
specified or when set to 0, the default of
|
||||
<literal>25s</literal> is assumed.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -229,9 +229,9 @@
|
||||
<para>Controls whether credential data reported by
|
||||
<command>list</command> or <command>status</command> shall
|
||||
be augmented with data from
|
||||
<filename>/proc</filename>. When this is turned on the data
|
||||
<filename>/proc</filename>. When this is turned on, the data
|
||||
shown is possibly inconsistent, as the data read from
|
||||
<filename>/proc</filename> might be more recent than rest of
|
||||
<filename>/proc</filename> might be more recent than the rest of
|
||||
the credential information. Defaults to <literal>yes</literal>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -258,7 +258,7 @@
|
||||
<term><command>list</command></term>
|
||||
|
||||
<listitem><para>Show all peers on the bus, by their service
|
||||
names. By default shows both unique and well-known names, but
|
||||
names. By default, shows both unique and well-known names, but
|
||||
this may be changed with the <option>--unique</option> and
|
||||
<option>--acquired</option> switches. This is the default
|
||||
operation if no command is specified.</para></listitem>
|
||||
@ -281,14 +281,14 @@
|
||||
<replaceable>SERVICE</replaceable> is specified, show messages
|
||||
to or from this peer, identified by its well-known or unique
|
||||
name. Otherwise, show all messages on the bus. Use Ctrl-C to
|
||||
terminate dump.</para></listitem>
|
||||
terminate the dump.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><command>capture</command> <arg choice="opt" rep="repeat"><replaceable>SERVICE</replaceable></arg></term>
|
||||
|
||||
<listitem><para>Similar to <command>monitor</command> but
|
||||
writes the output in pcap format (for details see the <ulink
|
||||
writes the output in pcap format (for details, see the <ulink
|
||||
url="http://wiki.wireshark.org/Development/LibpcapFileFormat">Libpcap
|
||||
File Format</ulink> description. Make sure to redirect the
|
||||
output to STDOUT to a file. Tools like
|
||||
@ -312,7 +312,7 @@
|
||||
|
||||
<listitem><para>Show interfaces, methods, properties and
|
||||
signals of the specified object (identified by its path) on
|
||||
the specified service. If the interface argument is passed the
|
||||
the specified service. If the interface argument is passed, the
|
||||
output is limited to members of the specified
|
||||
interface.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -322,10 +322,10 @@
|
||||
|
||||
<listitem><para>Invoke a method and show the response. Takes a
|
||||
service name, object path, interface name and method name. If
|
||||
parameters shall be passed to the method call a signature
|
||||
parameters shall be passed to the method call, a signature
|
||||
string is required, followed by the arguments, individually
|
||||
formatted as strings. For details on the formatting used, see
|
||||
below. To suppress output of the returned data use the
|
||||
below. To suppress output of the returned data, use the
|
||||
<option>--quiet</option> option.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -335,16 +335,16 @@
|
||||
<listitem><para>Retrieve the current value of one or more
|
||||
object properties. Takes a service name, object path,
|
||||
interface name and property name. Multiple properties may be
|
||||
specified at once in which case their values will be shown one
|
||||
after the other, separated by newlines. The output is by
|
||||
default in terse format. Use <option>--verbose</option> for a
|
||||
specified at once, in which case their values will be shown one
|
||||
after the other, separated by newlines. The output is, by
|
||||
default, in terse format. Use <option>--verbose</option> for a
|
||||
more elaborate output format.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><command>set-property</command> <arg choice="plain"><replaceable>SERVICE</replaceable></arg> <arg choice="plain"><replaceable>OBJECT</replaceable></arg> <arg choice="plain"><replaceable>INTERFACE</replaceable></arg> <arg choice="plain"><replaceable>PROPERTY</replaceable></arg> <arg choice="plain"><replaceable>SIGNATURE</replaceable></arg> <arg choice="plain" rep="repeat"><replaceable>ARGUMENT</replaceable></arg></term>
|
||||
|
||||
<listitem><para>Set the current value an object
|
||||
<listitem><para>Set the current value of an object
|
||||
property. Takes a service name, object path, interface name,
|
||||
property name, property signature, followed by a list of
|
||||
parameters formatted as strings.</para></listitem>
|
||||
@ -364,19 +364,19 @@
|
||||
<para>The <command>call</command> and
|
||||
<command>set-property</command> commands take a signature string
|
||||
followed by a list of parameters formatted as string (for details
|
||||
on D-Bus signature strings see the <ulink
|
||||
on D-Bus signature strings, see the <ulink
|
||||
url="http://dbus.freedesktop.org/doc/dbus-specification.html#type-system">Type
|
||||
system chapter of the D-Bus specification</ulink>). For simple
|
||||
types each parameter following the signature should simply be the
|
||||
types, each parameter following the signature should simply be the
|
||||
parameter's value formatted as string. Positive boolean values may
|
||||
be formatted as <literal>true</literal>, <literal>yes</literal>,
|
||||
<literal>on</literal>, <literal>1</literal>; negative boolean
|
||||
<literal>on</literal>, or <literal>1</literal>; negative boolean
|
||||
values may be specified as <literal>false</literal>,
|
||||
<literal>no</literal>, <literal>off</literal>,
|
||||
<literal>no</literal>, <literal>off</literal>, or
|
||||
<literal>0</literal>. For arrays, a numeric argument for the
|
||||
number of entries followed by the entries shall be specified. For
|
||||
variants the signature of the contents shall be specified,
|
||||
followed by the contents. For dictionaries and structs the
|
||||
variants, the signature of the contents shall be specified,
|
||||
followed by the contents. For dictionaries and structs, the
|
||||
contents of them shall be directly specified.</para>
|
||||
|
||||
<para>For example,
|
||||
@ -395,7 +395,7 @@
|
||||
array that maps strings to variants, consisting of three
|
||||
entries. The string <literal>One</literal> is assigned the
|
||||
string <literal>Eins</literal>. The string
|
||||
<literal>Two</literal> is assigned the 32bit unsigned
|
||||
<literal>Two</literal> is assigned the 32-bit unsigned
|
||||
integer 2. The string <literal>Yes</literal> is assigned a
|
||||
positive boolean.</para>
|
||||
|
||||
@ -456,8 +456,8 @@ ARRAY "s" {
|
||||
of the <literal>org.freedesktop.systemd1</literal>
|
||||
service, and passes it two strings
|
||||
<literal>cups.service</literal> and
|
||||
<literal>replace</literal>. As result of the method
|
||||
call a single object path parameter is received and
|
||||
<literal>replace</literal>. As a result of the method
|
||||
call, a single object path parameter is received and
|
||||
shown:</para>
|
||||
|
||||
<programlisting># busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager StartUnit ss "cups.service" "replace"
|
||||
|
||||
@ -98,7 +98,7 @@
|
||||
<term><varname>Compress=</varname></term>
|
||||
|
||||
<listitem><para>Controls compression for external
|
||||
storage. Takes a boolean argument, defaults to
|
||||
storage. Takes a boolean argument, which defaults to
|
||||
<literal>yes</literal>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -135,7 +135,7 @@
|
||||
coredumps are processed. Note that old coredumps are also
|
||||
removed based on time via
|
||||
<citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Set
|
||||
either value to 0 to turn off size based
|
||||
either value to 0 to turn off size-based
|
||||
clean-up.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
@ -160,10 +160,10 @@
|
||||
at the beginning. This is different from the <option>--offset</option>
|
||||
option with respect to the sector numbers used in initialization vector
|
||||
(IV) calculation. Using <option>--offset</option> will shift the IV
|
||||
calculation by the same negative amount. Hence, if <option>--offset n</option>,
|
||||
calculation by the same negative amount. Hence, if <option>--offset n</option> is given,
|
||||
sector n will get a sector number of 0 for the IV calculation.
|
||||
Using <option>--skip</option> causes sector n to also be the first
|
||||
sector of the mapped device, but with its number for IV generation is n.</para>
|
||||
sector of the mapped device, but with its number for IV generation being n.</para>
|
||||
|
||||
<para>This option is only relevant for plain devices.</para>
|
||||
</listitem>
|
||||
|
||||
@ -125,7 +125,7 @@
|
||||
|
||||
<!--
|
||||
- helper template to do conflict resolution between various headings with the same inferred ID attribute/tag from the headerlink template
|
||||
- this conflict resolution is necessary to prevent malformed HTML output (multiple id attributes with the same value)
|
||||
- this conflict resolution is necessary to prevent malformed HTML output (multiple ID attributes with the same value)
|
||||
- and it fixes xsltproc warnings during compilation of HTML man pages
|
||||
-
|
||||
- A simple top-to-bottom numbering scheme is implemented for nodes with the same ID value to derive unique ID values for HTML output.
|
||||
@ -171,7 +171,7 @@
|
||||
<!--
|
||||
- If stable URLs with fragment markers (references to the ID) turn out not to be important:
|
||||
- generatedID could simply take the value of generate-id(), and various other helper templates may be dropped entirely.
|
||||
- Alternatively if xsltproc is patched to generate reproducible generate-id() output the same simplifications can be
|
||||
- Alternatively, if xsltproc is patched to generate reproducible generate-id() output, the same simplifications can be
|
||||
- applied at the cost of breaking compatibility with URLs generated from output of previous versions of this stylesheet.
|
||||
-->
|
||||
<xsl:variable name="generatedID">
|
||||
|
||||
@ -490,13 +490,13 @@
|
||||
configured address redundant. Another often suggested trigger
|
||||
for service activation is low system load. However, here too, a
|
||||
more convincing approach might be to make proper use of features
|
||||
of the operating system, in particular, the CPU or IO scheduler
|
||||
of the operating system, in particular, the CPU or I/O scheduler
|
||||
of Linux. Instead of scheduling jobs from userspace based on
|
||||
monitoring the OS scheduler, it is advisable to leave the
|
||||
scheduling of processes to the OS scheduler itself. systemd
|
||||
provides fine-grained access to the CPU and IO schedulers. If a
|
||||
provides fine-grained access to the CPU and I/O schedulers. If a
|
||||
process executed by the init system shall not negatively impact
|
||||
the amount of CPU or IO bandwidth available to other processes,
|
||||
the amount of CPU or I/O bandwidth available to other processes,
|
||||
it should be configured with
|
||||
<varname>CPUSchedulingPolicy=idle</varname> and/or
|
||||
<varname>IOSchedulingClass=idle</varname>. Optionally, this may
|
||||
|
||||
@ -84,7 +84,7 @@
|
||||
<varlistentry>
|
||||
<term><filename>/boot</filename></term>
|
||||
<listitem><para>The boot partition used for bringing up the
|
||||
system. On EFI systems this is possibly the EFI System
|
||||
system. On EFI systems, this is possibly the EFI System
|
||||
Partition, also see
|
||||
<citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
|
||||
This directory is usually strictly local to the host, and
|
||||
@ -147,14 +147,14 @@
|
||||
directory is usually mounted as a <literal>tmpfs</literal>
|
||||
instance, and should hence not be used for larger files. (Use
|
||||
<filename>/var/tmp</filename> for larger files.) Since the
|
||||
directory is accessible to other users of the system it is
|
||||
directory is accessible to other users of the system, it is
|
||||
essential that this directory is only written to with the
|
||||
<citerefentry project='man-pages'><refentrytitle>mkstemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
<citerefentry project='man-pages'><refentrytitle>mkdtemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
and related calls. This directory is usually flushed at
|
||||
boot-up. Also, files that are not accessed within a certain
|
||||
time are usually automatically deleted. If applications find
|
||||
the environment variable <varname>$TMPDIR</varname> set they
|
||||
the environment variable <varname>$TMPDIR</varname> set, they
|
||||
should prefer using the directory specified in it over
|
||||
directly referencing <filename>/tmp</filename> (see
|
||||
<citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
@ -217,7 +217,7 @@
|
||||
|
||||
<varlistentry>
|
||||
<term><filename>/usr/bin</filename></term>
|
||||
<listitem><para>Binaries and executables for user commands,
|
||||
<listitem><para>Binaries and executables for user commands
|
||||
that shall appear in the <varname>$PATH</varname> search path.
|
||||
It is recommended not to place binaries in this directory that
|
||||
are not useful for invocation from a shell (such as daemon
|
||||
@ -245,7 +245,7 @@
|
||||
|
||||
<varlistentry>
|
||||
<term><filename>/usr/lib/<replaceable>arch-id</replaceable></filename></term>
|
||||
<listitem><para>Location for placing dynamic libraries, also
|
||||
<listitem><para>Location for placing dynamic libraries into, also
|
||||
called <varname>$libdir</varname>. The architecture identifier
|
||||
to use is defined on <ulink
|
||||
url="https://wiki.debian.org/Multiarch/Tuples">Multiarch
|
||||
@ -291,7 +291,7 @@
|
||||
<term><filename>/usr/share/factory/var</filename></term>
|
||||
|
||||
<listitem><para>Similar to
|
||||
<filename>/usr/share/factory/etc</filename> but for vendor
|
||||
<filename>/usr/share/factory/etc</filename>, but for vendor
|
||||
versions of files in the variable, persistent data directory
|
||||
<filename>/var</filename>.</para></listitem>
|
||||
|
||||
@ -353,7 +353,7 @@
|
||||
<varlistentry>
|
||||
<term><filename>/var/tmp</filename></term>
|
||||
<listitem><para>The place for larger and persistent temporary
|
||||
files. In contrast to <filename>/tmp</filename> this directory
|
||||
files. In contrast to <filename>/tmp</filename>, this directory
|
||||
is usually mounted from a persistent physical file system and
|
||||
can thus accept larger files. (Use <filename>/tmp</filename>
|
||||
for smaller files.) This directory is generally not flushed at
|
||||
@ -365,7 +365,7 @@
|
||||
<citerefentry project='man-pages'><refentrytitle>mkdtemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
or similar calls should be used to make use of this directory.
|
||||
If applications find the environment variable
|
||||
<varname>$TMPDIR</varname> set they should prefer using the
|
||||
<varname>$TMPDIR</varname> set, they should prefer using the
|
||||
directory specified in it over directly referencing
|
||||
<filename>/var/tmp</filename> (see
|
||||
<citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
@ -381,7 +381,7 @@
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><filename>/dev</filename></term>
|
||||
<listitem><para>The root directory for device nodes. Usually
|
||||
<listitem><para>The root directory for device nodes. Usually,
|
||||
this directory is mounted as a <literal>devtmpfs</literal>
|
||||
instance, but might be of a different type in
|
||||
sandboxed/containerized setups. This directory is managed
|
||||
@ -402,10 +402,10 @@
|
||||
write access to this directory, special care should be taken
|
||||
to avoid name clashes and vulnerabilities. For normal users,
|
||||
shared memory segments in this directory are usually deleted
|
||||
when the user logs out. Usually it is a better idea to use
|
||||
when the user logs out. Usually, it is a better idea to use
|
||||
memory mapped files in <filename>/run</filename> (for system
|
||||
programs) or <varname>$XDG_RUNTIME_DIR</varname> (for user
|
||||
programs) instead of POSIX shared memory segments, since those
|
||||
programs) instead of POSIX shared memory segments, since these
|
||||
directories are not world-writable and hence not vulnerable to
|
||||
security-sensitive name clashes.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -427,7 +427,7 @@
|
||||
that exposes a number of kernel tunables. The primary way to
|
||||
configure the settings in this API file tree is via
|
||||
<citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
files. In sandboxed/containerized setups this directory is
|
||||
files. In sandboxed/containerized setups, this directory is
|
||||
generally mounted read-only.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -437,7 +437,7 @@
|
||||
discovered devices and other functionality. This file system
|
||||
is mostly an API to interface with the kernel and not a place
|
||||
where normal files may be stored. In sandboxed/containerized
|
||||
setups this directory is generally mounted read-only. A number
|
||||
setups, this directory is generally mounted read-only. A number
|
||||
of special purpose virtual file systems might be mounted below
|
||||
this directory.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -472,7 +472,7 @@
|
||||
<varlistentry>
|
||||
<term><filename>/lib64</filename></term>
|
||||
|
||||
<listitem><para>On some architecture ABIs this compatibility
|
||||
<listitem><para>On some architecture ABIs, this compatibility
|
||||
symlink points to <varname>$libdir</varname>, ensuring that
|
||||
binaries referencing this legacy path correctly find their
|
||||
dynamic loader. This symlink only exists on architectures
|
||||
@ -513,7 +513,7 @@
|
||||
directory should have no effect on operation of programs,
|
||||
except for increased runtimes necessary to rebuild these
|
||||
caches. If an application finds
|
||||
<varname>$XDG_CACHE_HOME</varname> set is should use the
|
||||
<varname>$XDG_CACHE_HOME</varname> set, it should use the
|
||||
directory specified in it instead of this
|
||||
directory.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -522,10 +522,10 @@
|
||||
<term><filename>~/.config</filename></term>
|
||||
|
||||
<listitem><para>Application configuration and state. When a
|
||||
new user is created this directory will be empty or not exist
|
||||
new user is created, this directory will be empty or not exist
|
||||
at all. Applications should fall back to defaults should their
|
||||
configuration or state in this directory be missing. If an
|
||||
application finds <varname>$XDG_CONFIG_HOME</varname> set is
|
||||
application finds <varname>$XDG_CONFIG_HOME</varname> set, it
|
||||
should use the directory specified in it instead of this
|
||||
directory.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -539,7 +539,7 @@
|
||||
invocation from a shell; these should be placed in a
|
||||
subdirectory of <filename>~/.local/lib</filename> instead.
|
||||
Care should be taken when placing architecture-dependent
|
||||
binaries in this place which might be problematic if the home
|
||||
binaries in this place, which might be problematic if the home
|
||||
directory is shared between multiple hosts with different
|
||||
architectures.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -555,7 +555,7 @@
|
||||
<term><filename>~/.local/lib/<replaceable>arch-id</replaceable></filename></term>
|
||||
|
||||
<listitem><para>Location for placing public dynamic libraries.
|
||||
The architecture identifier to use, is defined on <ulink
|
||||
The architecture identifier to use is defined on <ulink
|
||||
url="https://wiki.debian.org/Multiarch/Tuples">Multiarch
|
||||
Architecture Specifiers (Tuples)</ulink>
|
||||
list.</para></listitem>
|
||||
@ -568,7 +568,7 @@
|
||||
such as fonts or artwork. Usually, the precise location and
|
||||
format of files stored below this directory is subject to
|
||||
specifications that ensure interoperability. If an application
|
||||
finds <varname>$XDG_DATA_HOME</varname> set is should use the
|
||||
finds <varname>$XDG_DATA_HOME</varname> set, it should use the
|
||||
directory specified in it instead of this
|
||||
directory.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -593,11 +593,11 @@
|
||||
<filename>/run/user</filename>) of the user, which are all
|
||||
writable.</para>
|
||||
|
||||
<para>For unprivileged system processes only
|
||||
<para>For unprivileged system processes, only
|
||||
<filename>/tmp</filename>,
|
||||
<filename>/var/tmp</filename> and
|
||||
<filename>/dev/shm</filename> are writable. If an
|
||||
unprivileged system process needs a private, writable directory in
|
||||
unprivileged system process needs a private writable directory in
|
||||
<filename>/var</filename> or <filename>/run</filename>, it is
|
||||
recommended to either create it before dropping privileges in the
|
||||
daemon code, to create it via
|
||||
@ -618,7 +618,7 @@
|
||||
|
||||
<para>It is strongly recommended that <filename>/dev</filename> is
|
||||
the only location below which device nodes shall be placed.
|
||||
Similar, <filename>/run</filename> shall be the only location to
|
||||
Similarly, <filename>/run</filename> shall be the only location to
|
||||
place sockets and FIFOs. Regular files, directories and symlinks
|
||||
may be used in all directories.</para>
|
||||
</refsect1>
|
||||
@ -645,7 +645,7 @@
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><filename>/usr/bin</filename></entry>
|
||||
<entry>Package executables that shall appear in the <varname>$PATH</varname> executable search path, compiled for any of the supported architectures compatible with the operating system. It is not recommended to place internal binaries or binaries that are not commonly invoked from the shell in this directory, such as daemon binaries. As this directory is shared with most other packages of the system special care should be taken to pick unique names for files placed here, that are unlikely to clash with other package's files.</entry>
|
||||
<entry>Package executables that shall appear in the <varname>$PATH</varname> executable search path, compiled for any of the supported architectures compatible with the operating system. It is not recommended to place internal binaries or binaries that are not commonly invoked from the shell in this directory, such as daemon binaries. As this directory is shared with most other packages of the system, special care should be taken to pick unique names for files placed here, that are unlikely to clash with other package's files.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><filename>/usr/lib/<replaceable>arch-id</replaceable></filename></entry>
|
||||
@ -653,7 +653,7 @@
|
||||
</row>
|
||||
<row>
|
||||
<entry><filename>/usr/lib/<replaceable>package</replaceable></filename></entry>
|
||||
<entry>Private, static vendor resources of the package, including private binaries and libraries, or any other kind of read-only vendor data.</entry>
|
||||
<entry>Private static vendor resources of the package, including private binaries and libraries, or any other kind of read-only vendor data.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><filename>/usr/lib/<replaceable>arch-id</replaceable>/<replaceable>package</replaceable></filename></entry>
|
||||
@ -668,10 +668,10 @@
|
||||
</table>
|
||||
|
||||
<para>Additional static vendor files may be installed in the
|
||||
<filename>/usr/share</filename> hierarchy, to the locations
|
||||
<filename>/usr/share</filename> hierarchy to the locations
|
||||
defined by the various relevant specifications.</para>
|
||||
|
||||
<para>During runtime and for local configuration and state
|
||||
<para>During runtime, and for local configuration and state,
|
||||
additional directories are defined:</para>
|
||||
|
||||
<table>
|
||||
@ -700,7 +700,7 @@
|
||||
</row>
|
||||
<row>
|
||||
<entry><filename>/var/cache/<replaceable>package</replaceable></filename></entry>
|
||||
<entry>Persistent cache data of the package. If this directory is flushed the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary.</entry>
|
||||
<entry>Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><filename>/var/lib/<replaceable>package</replaceable></filename></entry>
|
||||
@ -726,7 +726,7 @@
|
||||
when placing their own files in the user's home directory. The
|
||||
following table lists recommended locations in the home directory
|
||||
for specific types of files supplied by the vendor if the
|
||||
application is installed in the home directory. (Note however,
|
||||
application is installed in the home directory. (Note, however,
|
||||
that user applications installed system-wide should follow the
|
||||
rules outlined above regarding placing vendor files.)</para>
|
||||
|
||||
@ -744,7 +744,7 @@
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><filename>~/.local/bin</filename></entry>
|
||||
<entry>Package executables that shall appear in the <varname>$PATH</varname> executable search path. It is not recommended to place internal executables or executables that are not commonly invoked from the shell in this directory, such as daemon executables. As this directory is shared with most other packages of the user special care should be taken to pick unique names for files placed here, that are unlikely to clash with other package's files.</entry>
|
||||
<entry>Package executables that shall appear in the <varname>$PATH</varname> executable search path. It is not recommended to place internal executables or executables that are not commonly invoked from the shell in this directory, such as daemon executables. As this directory is shared with most other packages of the user, special care should be taken to pick unique names for files placed here, that are unlikely to clash with other package's files.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><filename>~/.local/lib/<replaceable>arch-id</replaceable></filename></entry>
|
||||
@ -763,10 +763,10 @@
|
||||
</table>
|
||||
|
||||
<para>Additional static vendor files may be installed in the
|
||||
<filename>~/.local/share</filename> hierarchy, to the locations
|
||||
<filename>~/.local/share</filename> hierarchy to the locations
|
||||
defined by the various relevant specifications.</para>
|
||||
|
||||
<para>During runtime and for local configuration and state
|
||||
<para>During runtime, and for local configuration and state,
|
||||
additional directories are defined:</para>
|
||||
|
||||
<table>
|
||||
@ -791,7 +791,7 @@
|
||||
</row>
|
||||
<row>
|
||||
<entry><filename>~/.cache/<replaceable>package</replaceable></filename></entry>
|
||||
<entry>Persistent cache data of the package. If this directory is flushed the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary.</entry>
|
||||
<entry>Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
||||
@ -34,7 +34,7 @@
|
||||
|
||||
<refsect1><title>Description</title>
|
||||
<para>The hardware database is a key-value store for associating modalias-like keys to
|
||||
udev-properties-like values. It is used primarily by udev to add the relevant properties
|
||||
udev-property-like values. It is used primarily by udev to add the relevant properties
|
||||
to matching devices, but it can also be queried directly.</para>
|
||||
</refsect1>
|
||||
|
||||
@ -55,9 +55,9 @@
|
||||
|
||||
<para>The hwdb file contains data records consisting of matches and
|
||||
associated key-value pairs. Every record in the hwdb starts with one or
|
||||
more match string, specifying a shell glob to compare the database
|
||||
more match strings, specifying a shell glob to compare the database
|
||||
lookup string against. Multiple match lines are specified in additional
|
||||
consecutive lines. Every match line is compared individually, they are
|
||||
consecutive lines. Every match line is compared individually, and they are
|
||||
combined by OR. Every match line must start at the first character of
|
||||
the line.</para>
|
||||
|
||||
@ -71,7 +71,7 @@
|
||||
and compiled to a binary database located at <filename>/etc/udev/hwdb.bin</filename>,
|
||||
or alternatively <filename>/usr/lib/udev/hwdb.bin</filename> if you want ship the compiled
|
||||
database in an immutable image.
|
||||
During runtime only the binary database is used.</para>
|
||||
During runtime, only the binary database is used.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
||||
@ -82,7 +82,7 @@
|
||||
matches apply to the same field, then they are automatically
|
||||
matched as alternatives, i.e. the resulting output will show
|
||||
entries matching any of the specified matches for the same
|
||||
field. Finally, the character <literal>+</literal> may appears
|
||||
field. Finally, the character <literal>+</literal> may appear
|
||||
as a separate word between other terms on the command line. This
|
||||
causes all matches before and after to be combined in a
|
||||
disjunction (i.e. logical OR).</para>
|
||||
@ -95,7 +95,7 @@
|
||||
<literal>_KERNEL_DEVICE=</literal> match for the device.</para>
|
||||
|
||||
<para>Additional constraints may be added using options
|
||||
<option>--boot</option>, <option>--unit=</option>, etc, to
|
||||
<option>--boot</option>, <option>--unit=</option>, etc., to
|
||||
further limit what entries will be shown (logical AND).</para>
|
||||
|
||||
<para>Output is interleaved from all accessible journal files,
|
||||
@ -181,7 +181,7 @@
|
||||
<option>-n1000</option> to guarantee that the pager will not
|
||||
buffer logs of unbounded size. This may be overridden with
|
||||
an explicit <option>-n</option> with some other numeric
|
||||
value while <option>-nall</option> will disable this cap.
|
||||
value, while <option>-nall</option> will disable this cap.
|
||||
Note that this option is only supported for the
|
||||
<citerefentry project='man-pages'><refentrytitle>less</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
pager.</para></listitem>
|
||||
@ -656,18 +656,18 @@
|
||||
<listitem><para>Removes archived journal files until the disk
|
||||
space they use falls below the specified size (specified with
|
||||
the usual <literal>K</literal>, <literal>M</literal>,
|
||||
<literal>G</literal>, <literal>T</literal> suffixes), or all
|
||||
<literal>G</literal> and <literal>T</literal> suffixes), or all
|
||||
journal files contain no data older than the specified
|
||||
timespan (specified with the usual <literal>s</literal>,
|
||||
<literal>min</literal>, <literal>h</literal>,
|
||||
<literal>days</literal>, <literal>months</literal>,
|
||||
<literal>weeks</literal>, <literal>years</literal> suffixes),
|
||||
<literal>weeks</literal> and <literal>years</literal> suffixes),
|
||||
or no more than the specified number of separate journal files
|
||||
remain. Note that running <option>--vacuum-size=</option> has
|
||||
only indirect effect on the output shown by
|
||||
<option>--disk-usage</option> as the latter includes active
|
||||
only an indirect effect on the output shown by
|
||||
<option>--disk-usage</option>, as the latter includes active
|
||||
journal files, while the vacuuming operation only operates
|
||||
on archived journal files. Similar,
|
||||
on archived journal files. Similarly,
|
||||
<option>--vacuum-files=</option> might not actually reduce the
|
||||
number of journal files to below the specified number, as it
|
||||
will not remove active journal
|
||||
@ -772,7 +772,7 @@
|
||||
<varlistentry>
|
||||
<term><option>--flush</option></term>
|
||||
|
||||
<listitem><para>Asks the Journal daemon to flush any log data
|
||||
<listitem><para>Asks the journal daemon to flush any log data
|
||||
stored in <filename>/run/log/journal</filename> into
|
||||
<filename>/var/log/journal</filename>, if persistent storage is
|
||||
enabled. This call does not return until the operation is
|
||||
@ -782,7 +782,7 @@
|
||||
<varlistentry>
|
||||
<term><option>--rotate</option></term>
|
||||
|
||||
<listitem><para>Asks the Journal daemon to rotate journal files.
|
||||
<listitem><para>Asks the journal daemon to rotate journal files.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
<xi:include href="standard-options.xml" xpointer="help" />
|
||||
|
||||
@ -203,7 +203,7 @@
|
||||
|
||||
<para><varname>SystemMaxUse=</varname> and
|
||||
<varname>RuntimeMaxUse=</varname> control how much disk space
|
||||
the journal may use up at maximum.
|
||||
the journal may use up at most.
|
||||
<varname>SystemKeepFree=</varname> and
|
||||
<varname>RuntimeKeepFree=</varname> control how much disk
|
||||
space systemd-journald shall leave free for other uses.
|
||||
@ -220,12 +220,12 @@
|
||||
enough free space before and journal files were created, and
|
||||
subsequently something else causes the file system to fill up,
|
||||
journald will stop using more space, but it will not be
|
||||
removing existing files to reduce footprint again
|
||||
removing existing files to reduce the footprint again,
|
||||
either.</para>
|
||||
|
||||
<para><varname>SystemMaxFileSize=</varname> and
|
||||
<varname>RuntimeMaxFileSize=</varname> control how large
|
||||
individual journal files may grow at maximum. This influences
|
||||
individual journal files may grow at most. This influences
|
||||
the granularity in which disk space is made available through
|
||||
rotation, i.e. deletion of historic data. Defaults to one
|
||||
eighth of the values configured with
|
||||
@ -234,17 +234,17 @@
|
||||
rotated journal files are kept as history.</para>
|
||||
|
||||
<para>Specify values in bytes or use K, M, G, T, P, E as
|
||||
units for the specified sizes (equal to 1024, 1024²,... bytes).
|
||||
units for the specified sizes (equal to 1024, 1024², ... bytes).
|
||||
Note that size limits are enforced synchronously when journal
|
||||
files are extended, and no explicit rotation step triggered by
|
||||
time is needed.</para>
|
||||
|
||||
<para><varname>SystemMaxFiles=</varname> and
|
||||
<varname>RuntimeMaxFiles=</varname> control how many
|
||||
individual journal files to keep at maximum. Note that only
|
||||
individual journal files to keep at most. Note that only
|
||||
archived files are deleted to reduce the number of files until
|
||||
this limit is reached; active files will stay around. This
|
||||
means that in effect there might still be more journal files
|
||||
means that, in effect, there might still be more journal files
|
||||
around in total than this limit after a vacuuming operation is
|
||||
complete. This setting defaults to 100.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -345,7 +345,7 @@
|
||||
<literal>notice</literal>,
|
||||
<literal>info</literal>,
|
||||
<literal>debug</literal>,
|
||||
or integer values in the range of 0..7 (corresponding to the
|
||||
or integer values in the range of 0–7 (corresponding to the
|
||||
same levels). Messages equal or below the log level specified
|
||||
are stored/forwarded, messages above are dropped. Defaults to
|
||||
<literal>debug</literal> for <varname>MaxLevelStore=</varname>
|
||||
@ -375,15 +375,15 @@
|
||||
|
||||
<para>
|
||||
Journal events can be transferred to a different logging daemon
|
||||
in two different ways. In the first method, messages are
|
||||
in two different ways. With the first method, messages are
|
||||
immediately forwarded to a socket
|
||||
(<filename>/run/systemd/journal/syslog</filename>), where the
|
||||
traditional syslog daemon can read them. This method is
|
||||
controlled by <varname>ForwardToSyslog=</varname> option. In a
|
||||
controlled by the <varname>ForwardToSyslog=</varname> option. With a
|
||||
second method, a syslog daemon behaves like a normal journal
|
||||
client, and reads messages from the journal files, similarly to
|
||||
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
|
||||
In this method, messages do not have to be read immediately,
|
||||
With this, messages do not have to be read immediately,
|
||||
which allows a logging daemon which is only started late in boot
|
||||
to access all messages since the start of the system. In
|
||||
addition, full structured meta-data is available to it. This
|
||||
|
||||
@ -75,7 +75,7 @@
|
||||
a udev context. Furthermore, multiple different udev contexts can
|
||||
be used in parallel by multiple threads. However, a single context
|
||||
must not be accessed by multiple threads in parallel. The caller
|
||||
is responsible of providing suitable locking if they intend to use
|
||||
is responsible for providing suitable locking if they intend to use
|
||||
it from multiple threads.</para>
|
||||
|
||||
<para>To introspect a local device on a system, a udev device
|
||||
@ -99,11 +99,11 @@
|
||||
|
||||
<para>Furthermore, libudev also exports legacy APIs that should
|
||||
not be used by new software (and as such are not documented as
|
||||
part of this manual). This includes the hardware-database known
|
||||
part of this manual). This includes the hardware database known
|
||||
as <constant>udev_hwdb</constant> (please use the new
|
||||
<citerefentry><refentrytitle>sd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
API instead) and the <constant>udev_queue</constant> object to
|
||||
query the udev-daemon (which should not be used by new software
|
||||
query the udev daemon (which should not be used by new software
|
||||
at all).</para>
|
||||
</refsect1>
|
||||
|
||||
|
||||
@ -54,7 +54,7 @@
|
||||
<title>Description</title>
|
||||
|
||||
<para>The <filename>/etc/locale.conf</filename> file configures
|
||||
system-wide locale settings. It is read at early-boot by
|
||||
system-wide locale settings. It is read at early boot by
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
|
||||
|
||||
<para>The basic file format of <filename>locale.conf</filename> is
|
||||
|
||||
@ -186,7 +186,7 @@
|
||||
<listitem><para>Show terse runtime status information about
|
||||
one or more sessions, followed by the most recent log data
|
||||
from the journal. Takes one or more session identifiers as
|
||||
parameters. If no session identifiers are passed the status of
|
||||
parameters. If no session identifiers are passed, the status of
|
||||
the caller's session is shown. This function is intended to
|
||||
generate human-readable output. If you are looking for
|
||||
computer-parsable output, use <command>show-session</command>
|
||||
@ -212,9 +212,9 @@
|
||||
<term><command>activate</command> <optional><replaceable>ID</replaceable></optional></term>
|
||||
|
||||
<listitem><para>Activate a session. This brings a session into
|
||||
the foreground, if another session is currently in the
|
||||
the foreground if another session is currently in the
|
||||
foreground on the respective seat. Takes a session identifier
|
||||
as argument. If no argument is specified the session of the
|
||||
as argument. If no argument is specified, the session of the
|
||||
caller is put into foreground.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -225,7 +225,7 @@
|
||||
<listitem><para>Activates/deactivates the screen lock on one
|
||||
or more sessions, if the session supports it. Takes one or
|
||||
more session identifiers as arguments. If no argument is
|
||||
specified the session of the caller is locked/unlocked.
|
||||
specified, the session of the caller is locked/unlocked.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -269,7 +269,7 @@
|
||||
<listitem><para>Show terse runtime status information about
|
||||
one or more logged in users, followed by the most recent log
|
||||
data from the journal. Takes one or more user names or numeric
|
||||
user IDs as parameters. If no parameters are passed the status
|
||||
user IDs as parameters. If no parameters are passed, the status
|
||||
of the caller's user is shown. This function is intended to
|
||||
generate human-readable output. If you are looking for
|
||||
computer-parsable output, use <command>show-user</command>
|
||||
@ -301,7 +301,7 @@
|
||||
spawned for the user at boot and kept around after logouts.
|
||||
This allows users who are not logged in to run long-running
|
||||
services. Takes one or more user names or numeric UIDs as
|
||||
argument. If no argument is specified enables/disables
|
||||
argument. If no argument is specified, enables/disables
|
||||
lingering for the user of the session of the caller.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
@ -365,7 +365,7 @@
|
||||
seat. The devices should be specified via device paths in the
|
||||
<filename>/sys</filename> file system. To create a new seat,
|
||||
attach at least one graphics card to a previously unused seat
|
||||
name. Seat names may consist only of a-z, A-Z, 0-9,
|
||||
name. Seat names may consist only of a–z, A–Z, 0–9,
|
||||
<literal>-</literal> and <literal>_</literal> and must be
|
||||
prefixed with <literal>seat</literal>. To drop assignment of a
|
||||
device to a specific seat, just reassign it to a different
|
||||
|
||||
@ -255,8 +255,8 @@
|
||||
|
||||
<listitem><para>Specifies the timeout after system startup or
|
||||
system resume in which systemd will hold off on reacting to
|
||||
LID events. This is required for the system to properly
|
||||
detect any hotplugged devices so systemd can ignore LID events
|
||||
lid events. This is required for the system to properly
|
||||
detect any hotplugged devices so systemd can ignore lid events
|
||||
if external monitors, or docks, are connected. If set to 0,
|
||||
systemd will always react immediately, possibly before the
|
||||
kernel fully probed all hotplugged devices. This is safe, as
|
||||
|
||||
@ -124,7 +124,7 @@
|
||||
<literal>tablet</literal>,
|
||||
<literal>handset</literal>,
|
||||
<literal>watch</literal>, and
|
||||
<literal>embedded</literal>
|
||||
<literal>embedded</literal>,
|
||||
as well as the special chassis types
|
||||
<literal>vm</literal> and
|
||||
<literal>container</literal> for
|
||||
|
||||
@ -83,9 +83,9 @@
|
||||
</itemizedlist>
|
||||
|
||||
<para>Machines are identified by names that follow the same rules
|
||||
as UNIX and DNS host names, for details see below. Machines are
|
||||
instantiated from disk or file system images, that frequently but not
|
||||
necessarily carry the same name as machines running from
|
||||
as UNIX and DNS host names, for details, see below. Machines are
|
||||
instantiated from disk or file system images that frequently — but not
|
||||
necessarily — carry the same name as machines running from
|
||||
them. Images in this sense are considered:</para>
|
||||
|
||||
<itemizedlist>
|
||||
@ -201,7 +201,7 @@
|
||||
<varlistentry>
|
||||
<term><option>--mkdir</option></term>
|
||||
|
||||
<listitem><para>When used with <command>bind</command> creates
|
||||
<listitem><para>When used with <command>bind</command>, creates
|
||||
the destination directory before applying the bind
|
||||
mount.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -209,7 +209,7 @@
|
||||
<varlistentry>
|
||||
<term><option>--read-only</option></term>
|
||||
|
||||
<listitem><para>When used with <command>bind</command> applies
|
||||
<listitem><para>When used with <command>bind</command>, applies
|
||||
a read-only bind mount.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -243,9 +243,9 @@
|
||||
specify whether the image shall be verified before it is made
|
||||
available. Takes one of <literal>no</literal>,
|
||||
<literal>checksum</literal> and <literal>signature</literal>.
|
||||
If <literal>no</literal> no verification is done. If
|
||||
<literal>checksum</literal> is specified the download is
|
||||
checked for integrity after transfer is complete, but no
|
||||
If <literal>no</literal>, no verification is done. If
|
||||
<literal>checksum</literal> is specified, the download is
|
||||
checked for integrity after the transfer is complete, but no
|
||||
signatures are verified. If <literal>signature</literal> is
|
||||
specified, the checksum is verified and the images's signature
|
||||
is checked against a local keyring of trustable vendors. It is
|
||||
@ -278,10 +278,10 @@
|
||||
<term><option>--format=</option></term>
|
||||
|
||||
<listitem><para>When used with the <option>export-tar</option>
|
||||
or <option>export-raw</option> commands specifies the
|
||||
or <option>export-raw</option> commands, specifies the
|
||||
compression format to use for the resulting file. Takes one of
|
||||
<literal>uncompressed</literal>, <literal>xz</literal>,
|
||||
<literal>gzip</literal>, <literal>bzip2</literal>. By default
|
||||
<literal>gzip</literal>, <literal>bzip2</literal>. By default,
|
||||
the format is determined automatically from the image file
|
||||
name passed.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -356,7 +356,7 @@
|
||||
image by the specified name in
|
||||
<filename>/var/lib/machines/</filename> (and other search
|
||||
paths, see below) and runs it. Use
|
||||
<command>list-images</command> (see below), for listing
|
||||
<command>list-images</command> (see below) for listing
|
||||
available container images to start.</para>
|
||||
|
||||
<para>Note that
|
||||
@ -381,7 +381,7 @@
|
||||
<term><command>login</command> [<replaceable>NAME</replaceable>]</term>
|
||||
|
||||
<listitem><para>Open an interactive terminal login session in
|
||||
a container or on the local host. If an argument is supplied
|
||||
a container or on the local host. If an argument is supplied,
|
||||
it refers to the container machine to connect to. If none is
|
||||
specified, or the container name is specified as the empty
|
||||
string, or the special machine name <literal>.host</literal>
|
||||
@ -414,7 +414,7 @@
|
||||
instead. This works similar to <command>login</command> but
|
||||
immediately invokes a user process. This command runs the
|
||||
specified executable with the specified arguments, or
|
||||
<filename>/bin/sh</filename> if none is specified. By default
|
||||
<filename>/bin/sh</filename> if none is specified. By default,
|
||||
opens a <literal>root</literal> shell, but by using
|
||||
<option>--uid=</option>, or by prefixing the machine name with
|
||||
a username and an <literal>@</literal> character, a different
|
||||
@ -422,10 +422,10 @@
|
||||
environment variables for the executed process.</para>
|
||||
|
||||
<para>When using the <command>shell</command> command without
|
||||
arguments (thus invoking the executed shell or command on the
|
||||
local host) it is similar in many ways to a <citerefentry
|
||||
arguments, (thus invoking the executed shell or command on the
|
||||
local host), it is in many ways similar to a <citerefentry
|
||||
project='die-net'><refentrytitle>su</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
session, but unlike <command>su</command> completely isolates
|
||||
session, but, unlike <command>su</command>, completely isolates
|
||||
the new session from the originating session, so that it
|
||||
shares no process or session properties, and is in a clean and
|
||||
well-defined state. It will be tracked in a new utmp, login,
|
||||
@ -433,7 +433,7 @@
|
||||
environment variables or resource limits, among other
|
||||
properties.</para>
|
||||
|
||||
<para>Note that the
|
||||
<para>Note that
|
||||
<citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
may be used in place of the <command>shell</command> command,
|
||||
and allows more detailed, low-level configuration of the
|
||||
@ -509,11 +509,11 @@
|
||||
specified container. The first directory argument is the
|
||||
source directory on the host, the second directory argument
|
||||
is the destination directory in the container. When the
|
||||
latter is omitted the destination path in the container is
|
||||
latter is omitted, the destination path in the container is
|
||||
the same as the source path on the host. When combined with
|
||||
the <option>--read-only</option> switch a ready-only bind
|
||||
the <option>--read-only</option> switch, a ready-only bind
|
||||
mount is created. When combined with the
|
||||
<option>--mkdir</option> switch the destination path is first
|
||||
<option>--mkdir</option> switch, the destination path is first
|
||||
created before the mount is applied. Note that this option is
|
||||
currently only supported for
|
||||
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
@ -526,7 +526,7 @@
|
||||
<listitem><para>Copies files or directories from the host
|
||||
system into a running container. Takes a container name,
|
||||
followed by the source path on the host and the destination
|
||||
path in the container. If the destination path is omitted the
|
||||
path in the container. If the destination path is omitted, the
|
||||
same as the source path is used.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -537,7 +537,7 @@
|
||||
<listitem><para>Copies files or directories from a container
|
||||
into the host system. Takes a container name, followed by the
|
||||
source path in the container the destination path on the host.
|
||||
If the destination path is omitted the same as the source path
|
||||
If the destination path is omitted, the same as the source path
|
||||
is used.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist></refsect2>
|
||||
@ -552,8 +552,8 @@
|
||||
directories and subvolumes in
|
||||
<filename>/var/lib/machines/</filename> (and other search
|
||||
paths, see below). Use <command>start</command> (see above) to
|
||||
run a container off one of the listed images. Note that by
|
||||
default containers whose name begins with a dot
|
||||
run a container off one of the listed images. Note that, by
|
||||
default, containers whose name begins with a dot
|
||||
(<literal>.</literal>) are not shown. To show these too,
|
||||
specify <option>--all</option>. Note that a special image
|
||||
<literal>.host</literal> always implicitly exists and refers
|
||||
@ -626,27 +626,27 @@
|
||||
|
||||
<listitem><para>Removes one or more container or VM images.
|
||||
The special image <literal>.host</literal>, which refers to
|
||||
the host's own directory tree may not be
|
||||
the host's own directory tree, may not be
|
||||
removed.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><command>set-limit</command> [<replaceable>NAME</replaceable>] <replaceable>BYTES</replaceable></term>
|
||||
|
||||
<listitem><para>Sets the maximum size in bytes a specific
|
||||
container or VM image, or all images may grow up to on disk
|
||||
<listitem><para>Sets the maximum size in bytes that a specific
|
||||
container or VM image, or all images, may grow up to on disk
|
||||
(disk quota). Takes either one or two parameters. The first,
|
||||
optional parameter refers to a container or VM image name. If
|
||||
specified the size limit of the specified image is changed. If
|
||||
omitted the overall size limit of the sum of all images stored
|
||||
specified, the size limit of the specified image is changed. If
|
||||
omitted, the overall size limit of the sum of all images stored
|
||||
locally is changed. The final argument specifies the size
|
||||
limit in bytes, possibly suffixed by the usual K, M, G, T
|
||||
units. If the size limit shall be disabled, specify
|
||||
<literal>-</literal> as size.</para>
|
||||
|
||||
<para>Note that per-container size limits are only supported
|
||||
on btrfs file systems. Also note that if
|
||||
<command>set-limit</command> is invoked without image
|
||||
on btrfs file systems. Also note that, if
|
||||
<command>set-limit</command> is invoked without an image
|
||||
parameter, and <filename>/var/lib/machines</filename> is
|
||||
empty, and the directory is not located on btrfs, a btrfs
|
||||
loopback file is implicitly created as
|
||||
@ -656,7 +656,7 @@
|
||||
loopback may later be readjusted with
|
||||
<command>set-limit</command>, as well. If such a
|
||||
loopback-mounted <filename>/var/lib/machines</filename>
|
||||
directory is used <command>set-limit</command> without image
|
||||
directory is used, <command>set-limit</command> without an image
|
||||
name alters both the quota setting within the file system as
|
||||
well as the loopback file and file system size
|
||||
itself.</para></listitem>
|
||||
@ -676,20 +676,20 @@
|
||||
<literal>https://</literal>, and must refer to a
|
||||
<filename>.tar</filename>, <filename>.tar.gz</filename>,
|
||||
<filename>.tar.xz</filename> or <filename>.tar.bz2</filename>
|
||||
archive file. If the local machine name is omitted it
|
||||
archive file. If the local machine name is omitted, it
|
||||
is automatically derived from the last component of the URL,
|
||||
with its suffix removed.</para>
|
||||
|
||||
<para>The image is verified before it is made available,
|
||||
unless <option>--verify=no</option> is specified. Verification
|
||||
is done via SHA256SUMS and SHA256SUMS.gpg files, that need to
|
||||
is done via SHA256SUMS and SHA256SUMS.gpg files that need to
|
||||
be made available on the same web server, under the same URL
|
||||
as the <filename>.tar</filename> file, but with the last
|
||||
component (the filename) of the URL replaced. With
|
||||
<option>--verify=checksum</option> only the SHA256 checksum
|
||||
<option>--verify=checksum</option>, only the SHA256 checksum
|
||||
for the file is verified, based on the
|
||||
<filename>SHA256SUMS</filename> file. With
|
||||
<option>--verify=signature</option> the SHA256SUMS file is
|
||||
<option>--verify=signature</option>, the SHA256SUMS file is
|
||||
first verified with detached GPG signature file
|
||||
<filename>SHA256SUMS.gpg</filename>. The public key for this
|
||||
verification step needs to be available in
|
||||
@ -698,7 +698,7 @@
|
||||
|
||||
<para>The container image will be downloaded and stored in a
|
||||
read-only subvolume in
|
||||
<filename>/var/lib/machines/</filename>, that is named after
|
||||
<filename>/var/lib/machines/</filename> that is named after
|
||||
the specified URL and its HTTP etag. A writable snapshot is
|
||||
then taken from this subvolume, and named after the specified
|
||||
local name. This behavior ensures that creating multiple
|
||||
@ -729,7 +729,7 @@
|
||||
be a <filename>.qcow2</filename> or raw disk image, optionally
|
||||
compressed as <filename>.gz</filename>,
|
||||
<filename>.xz</filename>, or <filename>.bz2</filename>. If the
|
||||
local machine name is omitted it is automatically
|
||||
local machine name is omitted, it is automatically
|
||||
derived from the last component of the URL, with its suffix
|
||||
removed.</para>
|
||||
|
||||
@ -801,22 +801,22 @@
|
||||
<listitem><para>Imports a TAR or RAW container or VM image,
|
||||
and places it under the specified name in
|
||||
<filename>/var/lib/machines/</filename>. When
|
||||
<command>import-tar</command> is used the file specified as
|
||||
first argument should be a tar archive, possibly compressed
|
||||
<command>import-tar</command> is used, the file specified as
|
||||
the first argument should be a tar archive, possibly compressed
|
||||
with xz, gzip or bzip2. It will then be unpacked into its own
|
||||
subvolume in <filename>/var/lib/machines</filename>. When
|
||||
<command>import-raw</command> is used the file should be a
|
||||
<command>import-raw</command> is used, the file should be a
|
||||
qcow2 or raw disk image, possibly compressed with xz, gzip or
|
||||
bzip2. If the second argument (the resulting image name) is
|
||||
not specified it is automatically derived from the file
|
||||
name. If the file name is passed as <literal>-</literal> the
|
||||
not specified, it is automatically derived from the file
|
||||
name. If the file name is passed as <literal>-</literal>, the
|
||||
image is read from standard input, in which case the second
|
||||
argument is mandatory.</para>
|
||||
|
||||
<para>Similar as with <command>pull-tar</command>,
|
||||
<command>pull-raw</command> the file system
|
||||
<filename>/var/lib/machines.raw</filename> is increased in
|
||||
size of necessary and appropriate. Optionally the
|
||||
size of necessary and appropriate. Optionally, the
|
||||
<option>--read-only</option> switch may be used to create a
|
||||
read-only container or VM image. No cryptographic validation
|
||||
is done when importing the images.</para>
|
||||
@ -833,11 +833,11 @@
|
||||
stores it in the specified file. The first parameter should be
|
||||
a VM or container image name. The second parameter should be a
|
||||
file path the TAR or RAW image is written to. If the path ends
|
||||
in <literal>.gz</literal> the file is compressed with gzip, if
|
||||
it ends in <literal>.xz</literal> with xz, and if it ends in
|
||||
<literal>.bz2</literal> with bzip2. If the path ends in
|
||||
neither the file is left uncompressed. If the second argument
|
||||
is missing the image is written to standard output. The
|
||||
in <literal>.gz</literal>, the file is compressed with gzip, if
|
||||
it ends in <literal>.xz</literal>, with xz, and if it ends in
|
||||
<literal>.bz2</literal>, with bzip2. If the path ends in
|
||||
neither, the file is left uncompressed. If the second argument
|
||||
is missing, the image is written to standard output. The
|
||||
compression may also be explicitly selected with the
|
||||
<option>--format=</option> switch. This is in particular
|
||||
useful if the second parameter is left unspecified.</para>
|
||||
@ -847,7 +847,7 @@
|
||||
aborted with
|
||||
<command>cancel-transfer</command>.</para>
|
||||
|
||||
<para>Note that currently only directory and subvolume images
|
||||
<para>Note that, currently, only directory and subvolume images
|
||||
may be exported as TAR images, and only raw disk images as RAW
|
||||
images.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -877,34 +877,34 @@
|
||||
<title>Machine and Image Names</title>
|
||||
|
||||
<para>The <command>machinectl</command> tool operates on machines
|
||||
and images, whose names must be chosen following strict
|
||||
and images whose names must be chosen following strict
|
||||
rules. Machine names must be suitable for use as host names
|
||||
following a conservative subset of DNS and UNIX/Linux
|
||||
semantics. Specifically, they must consist of one or more
|
||||
non-empty label strings, separated by dots. No leading or trailing
|
||||
dots are allowed. No sequences of multiple dots are allowed. The
|
||||
label strings may only consists of alphanumeric characters as well
|
||||
label strings may only consist of alphanumeric characters as well
|
||||
as the dash and underscore. The maximum length of a machine name
|
||||
is 64 characters.</para>
|
||||
|
||||
<para>A special machine with the name <literal>.host</literal>
|
||||
refers to the running host system itself. This is useful for execution
|
||||
operations or inspecting the host system as well. Not that
|
||||
operations or inspecting the host system as well. Note that
|
||||
<command>machinectl list</command> will not show this special
|
||||
machine unless the <option>--all</option> switch is specified.</para>
|
||||
|
||||
<para>Requirements on image names are less strict, however must be
|
||||
<para>Requirements on image names are less strict, however, they must be
|
||||
valid UTF-8, must be suitable as file names (hence not be the
|
||||
single or double dot, and not include a slash), and may not
|
||||
contain control characters. Since many operations search for an
|
||||
image by the name of a requested machine it is recommended to name
|
||||
image by the name of a requested machine, it is recommended to name
|
||||
images in the same strict fashion as machines.</para>
|
||||
|
||||
<para>A special image with the name <literal>.host</literal>
|
||||
refers to the image of the running host system. It is hence
|
||||
refers to the image of the running host system. It hence
|
||||
conceptually maps to the special <literal>.host</literal> machine
|
||||
name described above. Note that <command>machinectl
|
||||
list-images</command> won't show this special image either, unless
|
||||
list-images</command> will not show this special image either, unless
|
||||
<option>--all</option> is specified.</para>
|
||||
</refsect1>
|
||||
|
||||
@ -914,7 +914,7 @@
|
||||
<para>Machine images are preferably stored in
|
||||
<filename>/var/lib/machines/</filename>, but are also searched for
|
||||
in <filename>/usr/local/lib/machines/</filename> and
|
||||
<filename>/usr/lib/machines/</filename>. For compatibility reasons
|
||||
<filename>/usr/lib/machines/</filename>. For compatibility reasons,
|
||||
the directory <filename>/var/lib/container/</filename> is
|
||||
searched, too. Note that images stored below
|
||||
<filename>/usr</filename> are always considered read-only. It is
|
||||
@ -943,7 +943,7 @@
|
||||
<listitem><para>A simple directory tree, containing the files
|
||||
and directories of the container to boot.</para></listitem>
|
||||
|
||||
<listitem><para>A subvolume (on btrfs file systems), which are
|
||||
<listitem><para>Subvolumes (on btrfs file systems), which are
|
||||
similar to the simple directories, described above. However,
|
||||
they have additional benefits, such as efficient cloning and
|
||||
quota reporting.</para></listitem>
|
||||
@ -956,7 +956,7 @@
|
||||
|
||||
<para>See
|
||||
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
for more information on image formats, in particular it's
|
||||
for more information on image formats, in particular its
|
||||
<option>--directory=</option> and <option>--image=</option>
|
||||
options.</para>
|
||||
</refsect1>
|
||||
@ -987,7 +987,7 @@
|
||||
# machinectl login Fedora-Cloud-Base-20141203-21</programlisting>
|
||||
|
||||
<para>This downloads the specified <filename>.raw</filename>
|
||||
image with verification disabled. Then a shell is opened in it
|
||||
image with verification disabled. Then, a shell is opened in it
|
||||
and a root password is set. Afterwards the shell is left, and
|
||||
the machine started as system service. With the last command a
|
||||
login prompt into the container is requested.</para>
|
||||
@ -1010,8 +1010,8 @@
|
||||
|
||||
<programlisting># machinectl export-tar fedora myfedora.tar.xz</programlisting>
|
||||
|
||||
<para>Exports the container <literal>fedora</literal> in an
|
||||
xz-compress tar file <filename>myfedora.tar.xz</filename> in the
|
||||
<para>Exports the container <literal>fedora</literal> as an
|
||||
xz-compressed tar file <filename>myfedora.tar.xz</filename> into the
|
||||
current directory.</para>
|
||||
</example>
|
||||
|
||||
@ -1020,7 +1020,7 @@
|
||||
|
||||
<programlisting># machinectl shell --uid=lennart</programlisting>
|
||||
|
||||
<para>This creates a new shell session on the local host, for
|
||||
<para>This creates a new shell session on the local host for
|
||||
the user ID <literal>lennart</literal>, in a <citerefentry
|
||||
project='die-net'><refentrytitle>su</refentrytitle><manvolnum>1</manvolnum></citerefentry>-like
|
||||
fashion.</para>
|
||||
|
||||
@ -129,7 +129,7 @@ IDX LINK TYPE OPERATIONAL SETUP
|
||||
configured DNS servers, etc.</para>
|
||||
|
||||
<para>When no links are specified, routable links are
|
||||
shown. See also option <option>--all</option>.</para>
|
||||
shown. Also see the option <option>--all</option>.</para>
|
||||
|
||||
<para>Produces output similar to
|
||||
<programlisting>
|
||||
|
||||
@ -59,7 +59,7 @@
|
||||
|
||||
<para><command>nss-myhostname</command> is a plugin for the GNU
|
||||
Name Service Switch (NSS) functionality of the GNU C Library
|
||||
(<command>glibc</command>) primarily providing hostname resolution
|
||||
(<command>glibc</command>), primarily providing hostname resolution
|
||||
for the locally configured system hostname as returned by
|
||||
<citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
|
||||
The precise hostnames resolved by this module are:</para>
|
||||
@ -89,9 +89,9 @@
|
||||
time as changing the hostname. This is problematic since it
|
||||
requires a writable <filename>/etc</filename> file system and is
|
||||
fragile because the file might be edited by the administrator at
|
||||
the same time. With <command>nss-myhostname</command> enabled
|
||||
the same time. With <command>nss-myhostname</command> enabled,
|
||||
changing <filename>/etc/hosts</filename> is unnecessary, and on
|
||||
many systems the file becomes entirely optional.</para>
|
||||
many systems, the file becomes entirely optional.</para>
|
||||
|
||||
<para>To activate the NSS modules, <literal>myhostname</literal>
|
||||
has to be added to the line starting with
|
||||
@ -100,7 +100,7 @@
|
||||
|
||||
<para>It is recommended to place <literal>myhostname</literal>
|
||||
last in the <filename>nsswitch.conf</filename> line to make sure
|
||||
that this mapping is only used as fallback, and any DNS or
|
||||
that this mapping is only used as fallback, and that any DNS or
|
||||
<filename>/etc/hosts</filename> based mapping takes
|
||||
precedence.</para>
|
||||
</refsect1>
|
||||
@ -108,8 +108,8 @@
|
||||
<refsect1>
|
||||
<title>Example</title>
|
||||
|
||||
<para>Here's an example <filename>/etc/nsswitch.conf</filename>
|
||||
file, that enables <command>myhostname</command> correctly:</para>
|
||||
<para>Here is an example <filename>/etc/nsswitch.conf</filename>
|
||||
file that enables <command>myhostname</command> correctly:</para>
|
||||
|
||||
<programlisting>passwd: compat mymachines
|
||||
group: compat mymachines
|
||||
@ -135,7 +135,7 @@ netgroup: nis</programlisting>
|
||||
127.0.0.2 DGRAM
|
||||
127.0.0.2 RAW</programlisting>
|
||||
|
||||
<para>In this case the local hostname is <varname>omega</varname>.</para>
|
||||
<para>In this case, the local hostname is <varname>omega</varname>.</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
|
||||
@ -58,8 +58,8 @@
|
||||
|
||||
<para><command>nss-mymachines</command> is a plugin for the GNU
|
||||
Name Service Switch (NSS) functionality of the GNU C Library
|
||||
(<command>glibc</command>) providing hostname resolution for
|
||||
container names of containers running locally, that are registered
|
||||
(<command>glibc</command>), providing hostname resolution for
|
||||
container names of containers running locally that are registered
|
||||
with
|
||||
<citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
|
||||
The container names are resolved to the IP addresses of the
|
||||
@ -76,16 +76,16 @@
|
||||
|
||||
<para>It is recommended to place <literal>mymachines</literal>
|
||||
near the end of the <filename>nsswitch.conf</filename> lines to
|
||||
make sure that its mappings are only used as fallback, and any
|
||||
make sure that its mappings are only used as fallback, and that any
|
||||
other mappings, such as DNS or <filename>/etc/hosts</filename>
|
||||
based mappings take precedence.</para>
|
||||
based mappings, take precedence.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Example</title>
|
||||
|
||||
<para>Here's an example <filename>/etc/nsswitch.conf</filename>
|
||||
file, that enables <command>mymachines</command> correctly:</para>
|
||||
<para>Here is an example <filename>/etc/nsswitch.conf</filename>
|
||||
file that enables <command>mymachines</command> correctly:</para>
|
||||
|
||||
<programlisting>passwd: compat <command>mymachines</command>
|
||||
group: compat <command>mymachines</command>
|
||||
|
||||
@ -79,8 +79,8 @@
|
||||
<refsect1>
|
||||
<title>Example</title>
|
||||
|
||||
<para>Here's an example <filename>/etc/nsswitch.conf</filename>
|
||||
file, that enables <command>resolve</command> correctly:</para>
|
||||
<para>Here is an example <filename>/etc/nsswitch.conf</filename>
|
||||
file that enables <command>resolve</command> correctly:</para>
|
||||
|
||||
<programlisting>passwd: compat mymachines
|
||||
group: compat mymachines
|
||||
|
||||
@ -67,7 +67,7 @@
|
||||
without implementing a shell compatible execution engine. Variable
|
||||
assignment values must be enclosed in double or single quotes if
|
||||
they include spaces, semicolons or other special characters
|
||||
outside of A-Z, a-z, 0-9. Shell special characters ("$", quotes,
|
||||
outside of A–Z, a–z, 0–9. Shell special characters ("$", quotes,
|
||||
backslash, backtick) must be escaped with backslashes, following
|
||||
shell style. All strings should be in UTF-8 format, and
|
||||
non-printable characters should not be used. It is not supported
|
||||
@ -141,7 +141,7 @@
|
||||
<term><varname>ID=</varname></term>
|
||||
|
||||
<listitem><para>A lower-case string (no spaces or other
|
||||
characters outside of 0-9, a-z, ".", "_" and "-") identifying
|
||||
characters outside of 0–9, a–z, ".", "_" and "-") identifying
|
||||
the operating system, excluding any version information and
|
||||
suitable for processing by scripts or usage in generated
|
||||
filenames. If not set, defaults to
|
||||
@ -179,7 +179,7 @@
|
||||
<term><varname>VERSION_ID=</varname></term>
|
||||
|
||||
<listitem><para>A lower-case string (mostly numeric, no spaces
|
||||
or other characters outside of 0-9, a-z, ".", "_" and "-")
|
||||
or other characters outside of 0–9, a–z, ".", "_" and "-")
|
||||
identifying the operating system version, excluding any OS
|
||||
name information or release code name, and suitable for
|
||||
processing by scripts or usage in generated filenames. This
|
||||
@ -298,7 +298,7 @@
|
||||
|
||||
<listitem><para>
|
||||
A lower-case string (no spaces or other characters outside of
|
||||
0-9, a-z, ".", "_" and "-"), identifying a specific variant or
|
||||
0–9, a–z, ".", "_" and "-"), identifying a specific variant or
|
||||
edition of the operating system. This may be interpreted by
|
||||
other packages in order to determine a divergent default
|
||||
configuration. This field is optional and may not be
|
||||
|
||||
@ -197,7 +197,7 @@
|
||||
as <constant>AF_UNIX</constant> sockets, FIFOs, PID files and
|
||||
similar. It is guaranteed that this directory is local and
|
||||
offers the greatest possible file system feature set the
|
||||
operating system provides. For further details see the <ulink
|
||||
operating system provides. For further details, see the <ulink
|
||||
url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
|
||||
Base Directory Specification</ulink>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -59,7 +59,7 @@
|
||||
<title>Description</title>
|
||||
|
||||
<para>These configuration files control local DNS and LLMNR
|
||||
name resolving.</para>
|
||||
name resolution.</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
@ -72,12 +72,12 @@
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>DNS=</varname></term>
|
||||
<listitem><para>A space separated list of IPv4 and IPv6
|
||||
<listitem><para>A space-separated list of IPv4 and IPv6
|
||||
addresses to be used as system DNS servers. DNS requests are
|
||||
sent to one of the listed DNS servers in parallel to any
|
||||
per-interface DNS servers acquired from
|
||||
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
|
||||
For compatibility reasons, if set to the empty list the DNS
|
||||
For compatibility reasons, if set to the empty list, the DNS
|
||||
servers listed in <filename>/etc/resolv.conf</filename> are
|
||||
used, if any are configured there. This setting defaults to
|
||||
the empty list.</para></listitem>
|
||||
@ -85,7 +85,7 @@
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>FallbackDNS=</varname></term>
|
||||
<listitem><para>A space separated list of IPv4 and IPv6
|
||||
<listitem><para>A space-separated list of IPv4 and IPv6
|
||||
addresses to be used as the fallback DNS servers. Any
|
||||
per-interface DNS servers obtained from
|
||||
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
@ -103,9 +103,9 @@
|
||||
<literal>resolve</literal>. Controls Link-Local Multicast Name
|
||||
Resolution support (<ulink
|
||||
url="https://tools.ietf.org/html/rfc4795">RFC 4794</ulink>) on
|
||||
the local host. If true enables full LLMNR responder and
|
||||
resolver support. If false disable both. If set to
|
||||
<literal>resolve</literal> only resolving support is enabled,
|
||||
the local host. If true, enables full LLMNR responder and
|
||||
resolver support. If false, disables both. If set to
|
||||
<literal>resolve</literal>, only resolution support is enabled,
|
||||
but responding is disabled. Note that
|
||||
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
also maintains per-interface LLMNR settings. LLMNR will be
|
||||
|
||||
@ -121,10 +121,10 @@
|
||||
<title>Description</title>
|
||||
|
||||
<para>In addition to the error names user programs define, D-Bus
|
||||
knows a number of generic, standardized error names, that are
|
||||
knows a number of generic, standardized error names that are
|
||||
listed below.</para>
|
||||
|
||||
<para>In addition to this list, in sd-bus the special error
|
||||
<para>In addition to this list, in sd-bus, the special error
|
||||
namespace <literal>System.Error.</literal> is used to map
|
||||
arbitrary Linux system errors (as defined by <citerefentry
|
||||
project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
|
||||
@ -167,7 +167,7 @@
|
||||
<varlistentry>
|
||||
<term><varname>SD_BUS_ERROR_IO_ERROR</varname></term>
|
||||
<listitem><para>Generic input/output error, for example when
|
||||
accessing a socket or other IO context.</para></listitem>
|
||||
accessing a socket or other I/O context.</para></listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><varname>SD_BUS_ERROR_BAD_ADDRESS</varname></term>
|
||||
@ -186,7 +186,7 @@
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><varname>SD_BUS_ERROR_ACCESS_DENIED</varname></term>
|
||||
<listitem><para>Access to a resource has been denied, due to security restrictions.</para></listitem>
|
||||
<listitem><para>Access to a resource has been denied due to security restrictions.</para></listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><varname>SD_BUS_ERROR_AUTH_FAILED</varname></term>
|
||||
@ -224,7 +224,7 @@
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><varname>SD_BUS_ERROR_FILE_EXISTS</varname></term>
|
||||
<listitem><para>The requested file exists already.</para></listitem>
|
||||
<listitem><para>The requested file already exists.</para></listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><varname>SD_BUS_ERROR_UNKNOWN_METHOD</varname></term>
|
||||
@ -272,7 +272,7 @@
|
||||
<varlistentry>
|
||||
<term><varname>SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED</varname></term>
|
||||
<listitem><para>Access to the requested operation is not
|
||||
permitted, however, it might be available after interactive
|
||||
permitted. However, it might be available after interactive
|
||||
authentication. This is usually returned by method calls
|
||||
supporting a framework for additional interactive
|
||||
authorization, when interactive authorization was not enabled
|
||||
|
||||
@ -317,7 +317,7 @@
|
||||
to determine the mask of fields available.</para>
|
||||
|
||||
<para><function>sd_bus_creds_get_pid()</function> will retrieve
|
||||
the PID (process identifier). Similar,
|
||||
the PID (process identifier). Similarly,
|
||||
<function>sd_bus_creds_get_ppid()</function> will retrieve the
|
||||
parent PID. Note that PID 1 has no parent process, in which case
|
||||
-ENXIO is returned.</para>
|
||||
@ -326,14 +326,14 @@
|
||||
TID (thread identifier).</para>
|
||||
|
||||
<para><function>sd_bus_creds_get_uid()</function> will retrieve
|
||||
the numeric UID (user identifier). Similar,
|
||||
the numeric UID (user identifier). Similarly,
|
||||
<function>sd_bus_creds_get_euid()</function> returns the effective
|
||||
UID, <function>sd_bus_creds_get_suid()</function> the saved UID
|
||||
and <function>sd_bus_creds_get_fsuid()</function> the file system
|
||||
UID.</para>
|
||||
|
||||
<para><function>sd_bus_creds_get_gid()</function> will retrieve the
|
||||
numeric GID (group identifier). Similar,
|
||||
numeric GID (group identifier). Similarly,
|
||||
<function>sd_bus_creds_get_egid()</function> returns the effective
|
||||
GID, <function>sd_bus_creds_get_sgid()</function> the saved GID
|
||||
and <function>sd_bus_creds_get_fsgid()</function> the file system
|
||||
@ -355,7 +355,7 @@
|
||||
<para><function>sd_bus_creds_get_exe()</function> will retrieve
|
||||
the path to the program executable (as stored in the
|
||||
<filename>/proc/<replaceable>pid</replaceable>/exe</filename>
|
||||
link, but with <literal> (deleted)</literal> suffix removed). Note
|
||||
link, but with the <literal> (deleted)</literal> suffix removed). Note
|
||||
that kernel threads do not have an executable path, in which case
|
||||
-ENXIO is returned.</para>
|
||||
|
||||
@ -372,38 +372,38 @@
|
||||
|
||||
<para><function>sd_bus_creds_get_unit()</function> will retrieve
|
||||
the systemd unit name (in the system instance of systemd) that the
|
||||
process is part of. See
|
||||
process is a part of. See
|
||||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. For
|
||||
processes that are not part of a unit returns -ENXIO.
|
||||
processes that are not part of a unit, returns -ENXIO.
|
||||
</para>
|
||||
|
||||
<para><function>sd_bus_creds_get_user_unit()</function> will
|
||||
retrieve the systemd unit name (in the user instance of systemd)
|
||||
that the process is part of. See
|
||||
that the process is a part of. See
|
||||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. For
|
||||
processes that are not part of a user unit returns -ENXIO.
|
||||
processes that are not part of a user unit, returns -ENXIO.
|
||||
</para>
|
||||
|
||||
<para><function>sd_bus_creds_get_slice()</function> will retrieve
|
||||
the systemd slice (a unit in the system instance of systemd) that
|
||||
the process is part of. See
|
||||
<citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Similar,
|
||||
the process is a part of. See
|
||||
<citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Similarly,
|
||||
<function>sd_bus_creds_get_user_slice()</function> retrieves the
|
||||
systemd slice of the process, in the user instance of systemd.
|
||||
</para>
|
||||
|
||||
<para><function>sd_bus_creds_get_session()</function> will
|
||||
retrieve the identifier of the login session that the process is
|
||||
part of. See
|
||||
a part of. See
|
||||
<citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. For
|
||||
processes that are not part of a session returns -ENXIO.
|
||||
processes that are not part of a session, returns -ENXIO.
|
||||
</para>
|
||||
|
||||
<para><function>sd_bus_creds_get_owner_uid()</function> will
|
||||
retrieve the numeric UID (user identifier) of the user who owns
|
||||
the login session that the process is part of. See
|
||||
the login session that the process is a part of. See
|
||||
<citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
|
||||
For processes that are not part of a session returns -ENXIO.
|
||||
For processes that are not part of a session, returns -ENXIO.
|
||||
</para>
|
||||
|
||||
<para><function>sd_bus_creds_has_effective_cap()</function> will
|
||||
@ -494,7 +494,7 @@
|
||||
<varlistentry>
|
||||
<term><constant>-ENODATA</constant></term>
|
||||
|
||||
<listitem><para>Given field is not available in the
|
||||
<listitem><para>The given field is not available in the
|
||||
credentials object <parameter>c</parameter>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -502,7 +502,7 @@
|
||||
<varlistentry>
|
||||
<term><constant>-ENXIO</constant></term>
|
||||
|
||||
<listitem><para>Given field is not specified for the described
|
||||
<listitem><para>The given field is not specified for the described
|
||||
process or peer. This will be returned by
|
||||
<function>sd_bus_get_unit()</function>,
|
||||
<function>sd_bus_get_slice()</function>,
|
||||
@ -514,8 +514,8 @@
|
||||
slice, or logind session. It will also be returned by
|
||||
<function>sd_bus_creds_get_exe()</function> and
|
||||
<function>sd_bus_creds_get_cmdline()</function> for kernel
|
||||
threads (since these aren't started from an executable binary
|
||||
or have a command line),
|
||||
threads (since these are not started from an executable binary,
|
||||
nor have a command line), and by
|
||||
<function>sd_bus_creds_get_audit_session_id()</function> and
|
||||
<function>sd_bus_creds_get_audit_login_uid()</function> when
|
||||
the process is not part of an audit session, and
|
||||
|
||||
@ -130,7 +130,7 @@
|
||||
<para><function>sd_bus_creds_new_from_pid()</function> creates a
|
||||
new credentials object and fills it with information about the
|
||||
process <parameter>pid</parameter>. The pointer to this object
|
||||
will be stored in <parameter>ret</parameter> pointer. Note that
|
||||
will be stored in the <parameter>ret</parameter> pointer. Note that
|
||||
credential objects may also be created and retrieved via
|
||||
<citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
@ -171,11 +171,11 @@
|
||||
<constant>SD_BUS_CREDS_AUDIT_LOGIN_UID</constant>,
|
||||
<constant>SD_BUS_CREDS_TTY</constant>,
|
||||
<constant>SD_BUS_CREDS_UNIQUE_NAME</constant>,
|
||||
<constant>SD_BUS_CREDS_WELL_KNOWN_NAMES</constant>,
|
||||
<constant>SD_BUS_CREDS_WELL_KNOWN_NAMES</constant>, and
|
||||
<constant>SD_BUS_CREDS_DESCRIPTION</constant>. Use the special
|
||||
value <constant>_SD_BUS_CREDS_ALL</constant> to request all
|
||||
supported fields. The <constant>SD_BUS_CREDS_AUGMENT</constant>
|
||||
may not be ORed into the mask for invocations of
|
||||
constant may not be ORed into the mask for invocations of
|
||||
<function>sd_bus_creds_new_from_pid()</function>.</para>
|
||||
|
||||
<para>Fields can be retrieved from the credentials object using
|
||||
@ -191,35 +191,35 @@
|
||||
subset of fields requested in <parameter>creds_mask</parameter>.
|
||||
</para>
|
||||
|
||||
<para>Similar to <function>sd_bus_creds_get_mask()</function> the
|
||||
<para>Similar to <function>sd_bus_creds_get_mask()</function>, the
|
||||
function <function>sd_bus_creds_get_augmented_mask()</function>
|
||||
returns a bitmask of field constants. The mask indicates which
|
||||
credential fields have been retrieved in a non-atomic fashion. For
|
||||
credential objects created via
|
||||
<function>sd_bus_creds_new_from_pid()</function> this mask will be
|
||||
<function>sd_bus_creds_new_from_pid()</function>, this mask will be
|
||||
identical to the mask returned by
|
||||
<function>sd_bus_creds_get_mask()</function>. However, for
|
||||
credential objects retrieved via
|
||||
<function>sd_bus_get_name_creds()</function> this mask will be set
|
||||
<function>sd_bus_get_name_creds()</function>, this mask will be set
|
||||
for the credential fields that could not be determined atomically
|
||||
at peer connection time, and which were later added by reading
|
||||
augmenting credential data from
|
||||
<filename>/proc</filename>. Similar, for credential objects
|
||||
retrieved via <function>sd_bus_get_owner_creds()</function> the
|
||||
<filename>/proc</filename>. Similarly, for credential objects
|
||||
retrieved via <function>sd_bus_get_owner_creds()</function>, the
|
||||
mask is set for the fields that could not be determined atomically
|
||||
at bus creation time, but have been augmented. Similar, for
|
||||
at bus creation time, but have been augmented. Similarly, for
|
||||
credential objects retrieved via
|
||||
<function>sd_bus_message_get_creds()</function> the mask is set
|
||||
<function>sd_bus_message_get_creds()</function>, the mask is set
|
||||
for the fields that could not be determined atomically at message
|
||||
send time, but have been augmented. The mask returned by
|
||||
sending time, but have been augmented. The mask returned by
|
||||
<function>sd_bus_creds_get_augmented_mask()</function> is always a
|
||||
subset of (or identical to) the mask returned by
|
||||
<function>sd_bus_creds_get_mask()</function> for the same
|
||||
object. The latter call hence returns all credential fields
|
||||
available in the credential object, the former then marks the
|
||||
subset of those that have been augmented. Note that augmented
|
||||
fields are unsuitable for authorization decisions as they may be
|
||||
retrieved at different times, thus being subject to races. Hence
|
||||
fields are unsuitable for authorization decisions, as they may be
|
||||
retrieved at different times, thus being subject to races. Hence,
|
||||
augmented fields should be used exclusively for informational
|
||||
purposes.
|
||||
</para>
|
||||
|
||||
@ -112,7 +112,7 @@
|
||||
connection object to the user bus when invoked in user context, or
|
||||
to the system bus otherwise. The connection object is associated
|
||||
with the calling thread. Each time the function is invoked from
|
||||
the same thread the same object is returned, but its reference
|
||||
the same thread, the same object is returned, but its reference
|
||||
count is increased by one, as long as at least one reference is
|
||||
kept. When the last reference to the connection is dropped (using
|
||||
the
|
||||
@ -120,8 +120,8 @@
|
||||
call), the connection is terminated. Note that the connection is
|
||||
not automatically terminated when the associated thread ends. It
|
||||
is important to drop the last reference to the bus connection
|
||||
explicitly before the thread ends or otherwise the connection will
|
||||
be leaked. Also, queued but unread or unwritten messages keep the
|
||||
explicitly before the thread ends, as otherwise, the connection will
|
||||
leak. Also, queued but unread or unwritten messages keep the
|
||||
bus referenced, see below.</para>
|
||||
|
||||
<para><function>sd_bus_default_user()</function> returns a user
|
||||
@ -139,14 +139,14 @@
|
||||
<function>sd_bus_open_system()</function> does the same, but
|
||||
connects to the system bus. In contrast to
|
||||
<function>sd_bus_default()</function>,
|
||||
<function>sd_bus_default_user()</function>,
|
||||
<function>sd_bus_default_system()</function> these calls return
|
||||
<function>sd_bus_default_user()</function>, and
|
||||
<function>sd_bus_default_system()</function>, these calls return
|
||||
new, independent connection objects that are not associated with
|
||||
the invoking thread and are not shared between multiple
|
||||
invocations. It is recommended to share connections per thread to
|
||||
efficiently make use the available resources. Thus, it is
|
||||
recommended to use <function>sd_bus_default()</function>,
|
||||
<function>sd_bus_default_user()</function>,
|
||||
<function>sd_bus_default_user()</function> and
|
||||
<function>sd_bus_default_system()</function> to connect to the
|
||||
user or system buses.</para>
|
||||
|
||||
@ -215,31 +215,31 @@
|
||||
|
||||
<para>Queued but unwritten/unread messages also keep a reference
|
||||
to their bus connection object. For this reason, even if an
|
||||
application dropped all references to a bus connection it might
|
||||
not get destroyed right-away. Until all incoming queued
|
||||
application dropped all references to a bus connection, it might
|
||||
not get destroyed right away. Until all incoming queued
|
||||
messages are read, and until all outgoing unwritten messages are
|
||||
written, the bus object will stay
|
||||
alive. <function>sd_bus_flush()</function> may be used to write
|
||||
all outgoing queued messages so they drop their references. To
|
||||
flush the unread incoming messages use
|
||||
flush the unread incoming messages, use
|
||||
<function>sd_bus_close()</function>, which will also close the bus
|
||||
connection. When using the default bus logic it is a good idea to
|
||||
connection. When using the default bus logic, it is a good idea to
|
||||
first invoke <function>sd_bus_flush()</function> followed by
|
||||
<function>sd_bus_close()</function> when a thread or process
|
||||
terminates, and thus its bus connection object should be
|
||||
freed.</para>
|
||||
|
||||
<para>The life-cycle of the default bus connection should be the
|
||||
<para>The life cycle of the default bus connection should be the
|
||||
responsibility of the code that creates/owns the thread the
|
||||
default bus connection object is associated with. Library code
|
||||
should neither call <function>sd_bus_flush()</function> nor
|
||||
<function>sd_bus_close()</function> on default bus objects unless
|
||||
it does so in its own private, self-allocated thread. Library code
|
||||
should not use the default bus object in other threads unless it
|
||||
is clear that the program using it will life-cycle the bus
|
||||
is clear that the program using it will life cycle the bus
|
||||
connection object and flush and close it before exiting from the
|
||||
thread. In libraries where it is not clear that the calling
|
||||
program will life-cycle the bus connection object it is hence
|
||||
program will life cycle the bus connection object, it is hence
|
||||
recommended to use <function>sd_bus_open_system()</function>
|
||||
instead of <function>sd_bus_default_system()</function> and
|
||||
related calls.</para>
|
||||
|
||||
@ -167,7 +167,7 @@
|
||||
<citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
but additional domain-specific errors may be defined by
|
||||
applications. The <structfield>message</structfield> field usually
|
||||
contains a human readable string describing the details, but might
|
||||
contains a human-readable string describing the details, but might
|
||||
be NULL. An unset <structname>sd_bus_error</structname> structure
|
||||
should have both fields initialized to NULL. Set an error
|
||||
structure to <constant>SD_BUS_ERROR_NULL</constant> in order to
|
||||
@ -189,20 +189,20 @@
|
||||
for a list of well-known error names. Additional error mappings
|
||||
may be defined with
|
||||
<citerefentry><refentrytitle>sd_bus_error_add_map</refentrytitle><manvolnum>3</manvolnum></citerefentry>. If
|
||||
<parameter>e</parameter> is NULL no error structure is initialized
|
||||
<parameter>e</parameter> is NULL, no error structure is initialized,
|
||||
but the error is still converted into an
|
||||
<varname>errno</varname>-style error. If
|
||||
<parameter>name</parameter> is <constant>NULL</constant>, it is
|
||||
assumed that no error occurred, and 0 is returned. This means that
|
||||
this function may be conveniently used in a
|
||||
<function>return</function> statement. If
|
||||
<parameter>message</parameter> is NULL no message is set. This
|
||||
<parameter>message</parameter> is NULL, no message is set. This
|
||||
call can fail if no memory may be allocated for the name and
|
||||
message strings, in which case an
|
||||
<constant>SD_BUS_ERROR_NO_MEMORY</constant> error might be set
|
||||
instead and -ENOMEM returned. Do not use this call on error
|
||||
instead and -ENOMEM be returned. Do not use this call on error
|
||||
structures that are already initialized. If you intend to reuse an
|
||||
error structure free the old data stored in it with
|
||||
error structure, free the old data stored in it with
|
||||
<function>sd_bus_error_free()</function> first.</para>
|
||||
|
||||
<para><function>sd_bus_error_setf()</function> is similar to
|
||||
@ -216,8 +216,8 @@
|
||||
are not copied internally, and must hence remain constant and
|
||||
valid for the lifetime of <parameter>e</parameter>. Use this call
|
||||
to avoid memory allocations when setting error structures. Since
|
||||
this call does not allocate memory it will not fail with an
|
||||
out-of-memory condition, as
|
||||
this call does not allocate memory, it will not fail with an
|
||||
out-of-memory condition as
|
||||
<function>sd_bus_error_set()</function> can, as described
|
||||
above. Alternatively, the
|
||||
<constant>SD_BUS_ERROR_MAKE_CONST()</constant> macro may be used
|
||||
@ -238,7 +238,7 @@
|
||||
convenient usage in <function>return</function> statements. This
|
||||
call might fail due to lack of memory, in which case an
|
||||
<constant>SD_BUS_ERROR_NO_MEMORY</constant> error is set instead,
|
||||
and -ENOMEM returned.</para>
|
||||
and -ENOMEM is returned.</para>
|
||||
|
||||
<para><function>sd_bus_error_set_errnof()</function> is similar to
|
||||
<function>sd_bus_error_set_errno()</function>, but in addition to
|
||||
@ -249,7 +249,7 @@
|
||||
<parameter>format</parameter> and the arguments.</para>
|
||||
|
||||
<para><function>sd_bus_error_set_errnofv()</function> is similar to
|
||||
<function>sd_bus_error_set_errnof()</function> but takes the
|
||||
<function>sd_bus_error_set_errnof()</function>, but takes the
|
||||
format string parameters as <citerefentry
|
||||
project='man-pages'><refentrytitle>va_arg</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
parameter list.</para>
|
||||
@ -295,10 +295,10 @@
|
||||
<title>Return Value</title>
|
||||
|
||||
<para>The functions <function>sd_bus_error_set()</function>,
|
||||
<function>sd_bus_error_setf()</function>,
|
||||
<function>sd_bus_error_setf()</function>, and
|
||||
<function>sd_bus_error_set_const()</function>, when successful,
|
||||
return the negative errno value corresponding to the
|
||||
<parameter>name</parameter> parameter. Functions
|
||||
<parameter>name</parameter> parameter. The functions
|
||||
<function>sd_bus_error_set_errno()</function>,
|
||||
<function>sd_bus_error_set_errnof()</function> and
|
||||
<function>sd_bus_error_set_errnofv()</function>, when successful,
|
||||
@ -331,7 +331,7 @@
|
||||
<title>Reference ownership</title>
|
||||
<para><structname>sd_bus_error</structname> is not reference
|
||||
counted. Users should destroy resources held by it by calling
|
||||
<function>sd_bus_error_free()</function>. Usually error structures
|
||||
<function>sd_bus_error_free()</function>. Usually, error structures
|
||||
are allocated on the stack or passed in as function parameters,
|
||||
but they may also be allocated dynamically, in which case it is
|
||||
the duty of the caller to <citerefentry
|
||||
|
||||
@ -87,7 +87,7 @@
|
||||
<citerefentry><refentrytitle>sd_bus_error_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
or
|
||||
<citerefentry><refentrytitle>sd_bus_error_get_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>. By
|
||||
default a number of generic, standardized mappings are known, as
|
||||
default, a number of generic, standardized mappings are known, as
|
||||
documented in
|
||||
<citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Use
|
||||
this call to add further, application-specific mappings.</para>
|
||||
@ -95,12 +95,12 @@
|
||||
<para>The function takes a pointer to an array of
|
||||
<structname>sd_bus_error_map</structname> structures. A reference
|
||||
to the specified array is added to the lookup tables for error
|
||||
mappings. Note that the structure is not copied, it is hence
|
||||
mappings. Note that the structure is not copied, and that it is hence
|
||||
essential that the array stays available and constant during the
|
||||
entire remaining runtime of the process.</para>
|
||||
|
||||
<para>The mapping array should be put together with a series of
|
||||
<constant>SD_BUS_ERROR_MAP()</constant> macro invocations, that
|
||||
<constant>SD_BUS_ERROR_MAP()</constant> macro invocations that
|
||||
take a literal name string and a (positive)
|
||||
<varname>errno</varname>-style error number. The last entry of the
|
||||
array should be an invocation of the
|
||||
|
||||
@ -70,7 +70,7 @@
|
||||
appends a sequence of fields to the D-Bus message object
|
||||
<parameter>m</parameter>. The type string
|
||||
<parameter>types</parameter> describes the types of the field
|
||||
arguments that follow. For each type specified in the type string
|
||||
arguments that follow. For each type specified in the type string,
|
||||
one or more arguments need to be specified, in the same order as
|
||||
declared in the type string.</para>
|
||||
|
||||
|
||||
@ -131,8 +131,8 @@
|
||||
<parameter>type</parameter>. However, as a special exception, if
|
||||
the offset is specified as zero and the size specified as
|
||||
UINT64_MAX the full memory file descriptor contents is used. The
|
||||
memory file descriptor is sealed by this call if it hasn't been
|
||||
sealed yet, and cannot be modified a after this call. See
|
||||
memory file descriptor is sealed by this call if it has not been
|
||||
sealed yet, and cannot be modified after this call. See
|
||||
<citerefentry
|
||||
project='man-pages'><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
||||
for details about memory file descriptors. Appending arrays with
|
||||
@ -142,7 +142,7 @@
|
||||
process. Not all protocol transports support passing memory file
|
||||
descriptors between participants, in which case this call will
|
||||
automatically fall back to copying. Also, as memory file
|
||||
descriptor passing is inefficient for smaller amounts of data
|
||||
descriptor passing is inefficient for smaller amounts of data,
|
||||
copying might still be enforced even where memory file descriptor
|
||||
passing is supported.</para>
|
||||
|
||||
@ -150,13 +150,13 @@
|
||||
function appends an array of a trivial type to the message
|
||||
<parameter>m</parameter>, similar to
|
||||
<function>sd_bus_message_append_array()</function>. Contents of
|
||||
the IO vector array <parameter>iov</parameter> are used as the
|
||||
the I/O vector array <parameter>iov</parameter> are used as the
|
||||
contents of the array. The total size of
|
||||
<parameter>iov</parameter> payload (the sum of
|
||||
<structfield>iov_len</structfield> fields) must be a multiple of
|
||||
the size of the type <parameter>type</parameter>. The
|
||||
<parameter>iov</parameter> argument must point to
|
||||
<parameter>n</parameter> IO vector structures. Each structure may
|
||||
<parameter>n</parameter> I/O vector structures. Each structure may
|
||||
have the <structname>iov_base</structname> field set, in which
|
||||
case the memory pointed to will be copied into the message, or
|
||||
unset (set to zero), in which case a block of zeros of length
|
||||
@ -171,9 +171,9 @@
|
||||
copying items to the message, it returns a pointer to the
|
||||
destination area to the caller in pointer
|
||||
<parameter>p</parameter>. The caller should subsequently write the
|
||||
array contents to this memory. Modifications of the memory
|
||||
array contents to this memory. Modifications to the memory
|
||||
pointed to should only occur until the next operation on the bus
|
||||
message is invoked, most importantly the memory should not be
|
||||
message is invoked. Most importantly, the memory should not be
|
||||
altered anymore when another field has been added to the message
|
||||
or the message has been sealed.</para>
|
||||
</refsect1>
|
||||
|
||||
@ -83,7 +83,7 @@
|
||||
<citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
||||
for details.</para>
|
||||
|
||||
<para>Similar,
|
||||
<para>Similarly,
|
||||
<function>sd_bus_message_get_realtime_usec()</function> returns
|
||||
the realtime (wallclock) timestamp of the time the message was
|
||||
sent. This value is in microseconds since Jan 1st, 1970, i.e. in
|
||||
|
||||
@ -108,7 +108,7 @@
|
||||
<citerefentry><refentrytitle>sd_bus_message_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>sd_bus_message_get_seqnum</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
to query the timestamps of incoming messages. If negotiation is
|
||||
disabled or not supported these calls will fail with
|
||||
disabled or not supported, these calls will fail with
|
||||
<constant>-ENODATA</constant>. Note that not all transports
|
||||
support timestamping of messages. Specifically, timestamping is
|
||||
only available on the kdbus transport, but not on dbus1. The
|
||||
@ -118,7 +118,7 @@
|
||||
|
||||
<para><function>sd_bus_negotiate_creds()</function> controls
|
||||
whether and which implicit sender credentials shall be attached
|
||||
automatically to all incoming messages. Takes a bus object, a
|
||||
automatically to all incoming messages. Takes a bus object and a
|
||||
boolean indicating whether to enable or disable the credential
|
||||
parts encoded in the bit mask value argument. Note that not all
|
||||
transports support attaching sender credentials to messages, or do
|
||||
@ -140,10 +140,10 @@
|
||||
<citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Both
|
||||
<function>sd_bus_negotiate_timestamp()</function> and
|
||||
<function>sd_bus_negotiate_creds()</function> may also be called
|
||||
after a connection has been set up. Note that when operating on a
|
||||
after a connection has been set up. Note that, when operating on a
|
||||
connection that is shared between multiple components of the same
|
||||
program (for example via
|
||||
<citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
|
||||
<citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry>),
|
||||
it is highly recommended to only enable additional per message
|
||||
metadata fields, but never disable them again, in order not to
|
||||
disable functionality needed by other components.</para>
|
||||
|
||||
@ -84,7 +84,7 @@
|
||||
or a related call, and then start the connection with
|
||||
<citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
|
||||
|
||||
<para>In most cases it's a better idea to invoke
|
||||
<para>In most cases, it is a better idea to invoke
|
||||
<citerefentry><refentrytitle>sd_bus_default_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>sd_bus_default_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
or related calls instead of the more low-level
|
||||
|
||||
@ -128,23 +128,23 @@
|
||||
|
||||
<para><function>sd_bus_path_encode_many()</function> works like
|
||||
its counterpart <function>sd_bus_path_encode()</function>, but
|
||||
takes a path-template as argument and encodes multiple labels
|
||||
takes a path template as argument and encodes multiple labels
|
||||
according to its embedded directives. For each
|
||||
<literal>%</literal> character found in the template, the caller
|
||||
must provide a string via var-args, which will be encoded and
|
||||
must provide a string via varargs, which will be encoded and
|
||||
embedded at the position of the <literal>%</literal> character.
|
||||
Any other character in the template is copied verbatim into the
|
||||
encoded path.</para>
|
||||
|
||||
<para><function>sd_bus_path_decode_many()</function> does the
|
||||
reverse of <function>sd_bus_path_encode_many()</function>. It
|
||||
decodes the passed object path, according to the given
|
||||
path-template. For each <literal>%</literal> character in the
|
||||
decodes the passed object path according to the given
|
||||
path template. For each <literal>%</literal> character in the
|
||||
template, the caller must provide an output storage
|
||||
(<literal>char **</literal>) via var-args. The decoded label
|
||||
(<literal>char **</literal>) via varargs. The decoded label
|
||||
will be stored there. Each <literal>%</literal> character will
|
||||
only match the current label. It will never match across labels.
|
||||
Furthermore, only a single such directive is allowed per label.
|
||||
Furthermore, only a single directive is allowed per label.
|
||||
If <literal>NULL</literal> is passed as output storage, the
|
||||
label is verified but not returned to the caller.</para>
|
||||
</refsect1>
|
||||
|
||||
@ -157,7 +157,7 @@
|
||||
<varlistentry>
|
||||
<term><constant>-EBUSY</constant></term>
|
||||
|
||||
<listitem><para>An handler is already installed for this
|
||||
<listitem><para>A handler is already installed for this
|
||||
child.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
@ -90,7 +90,7 @@
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>Those three functions add new event sources to an event loop
|
||||
<para>These three functions add new event sources to an event loop
|
||||
object. The event loop is specified in
|
||||
<parameter>event</parameter>, the event source is returned in the
|
||||
<parameter>source</parameter> parameter. The event sources are
|
||||
|
||||
@ -82,7 +82,7 @@
|
||||
|
||||
<para><function>sd_event_add_signal()</function> adds a new signal
|
||||
event source to an event loop object. The event loop is specified
|
||||
in <parameter>event</parameter>, the event source is returned in
|
||||
in <parameter>event</parameter>, and the event source is returned in
|
||||
the <parameter>source</parameter> parameter. The
|
||||
<parameter>signal</parameter> parameter specifies the signal to be handled
|
||||
(see
|
||||
@ -149,7 +149,7 @@
|
||||
<varlistentry>
|
||||
<term><constant>-EBUSY</constant></term>
|
||||
|
||||
<listitem><para>An handler is already installed for this
|
||||
<listitem><para>A handler is already installed for this
|
||||
signal or the signal was not blocked previously.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
@ -114,7 +114,7 @@
|
||||
<function>sd_event_default()</function>, then releasing it, and
|
||||
then acquiring a new one with
|
||||
<function>sd_event_default()</function> will result in two
|
||||
distinct objects. Note that in order to free an event loop object,
|
||||
distinct objects. Note that, in order to free an event loop object,
|
||||
all remaining event sources of the event loop also need to be
|
||||
freed as each keeps a reference to it.</para>
|
||||
</refsect1>
|
||||
|
||||
@ -46,7 +46,7 @@
|
||||
<refname>sd_event_run</refname>
|
||||
<refname>sd_event_loop</refname>
|
||||
|
||||
<refpurpose>Run libsystemd event loop</refpurpose>
|
||||
<refpurpose>Run the libsystemd event loop</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
@ -71,8 +71,8 @@
|
||||
|
||||
<para><function>sd_event_run()</function> can be used to run one
|
||||
iteration of the event loop of libsystemd. This function waits
|
||||
until an event to process is available and dispatches a handler
|
||||
for it. Parameter <parameter>timeout</parameter> specifices the
|
||||
until an event to process is available, and dispatches a handler
|
||||
for it. The <parameter>timeout</parameter> parameter specifices the
|
||||
maximum time (in microseconds) to wait. <constant>(uint64_t)
|
||||
-1</constant> may be used to specify an infinite timeout.</para>
|
||||
|
||||
@ -121,7 +121,7 @@
|
||||
<varlistentry>
|
||||
<term><constant>-EINVAL</constant></term>
|
||||
|
||||
<listitem><para>Parameter <parameter>event</parameter> is
|
||||
<listitem><para>The <parameter>event</parameter> parameter is
|
||||
<constant>NULL</constant>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -150,7 +150,7 @@
|
||||
|
||||
</variablelist>
|
||||
|
||||
<para>Other errors are possible too.</para>
|
||||
<para>Other errors are possible, too.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@ -176,7 +176,7 @@
|
||||
<citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>sd_event_add_post</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
<ulink url="https://developer.gnome.org/glib/unstable/glib-The-Main-Event-Loop.html">GLIb Main Event Loop</ulink>.
|
||||
<ulink url="https://developer.gnome.org/glib/unstable/glib-The-Main-Event-Loop.html">GLib Main Event Loop</ulink>.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
|
||||
@ -77,7 +77,7 @@
|
||||
<parameter>source</parameter>. This name will be used in error
|
||||
messages generated by
|
||||
<citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
for this source. Specified <parameter>name</parameter> must point
|
||||
for this source. The <parameter>name</parameter> must point
|
||||
to a <constant>NUL</constant>-terminated string or be
|
||||
<constant>NULL</constant>. In the latter case, the name will be
|
||||
unset. The string is copied internally, so the
|
||||
@ -128,7 +128,7 @@
|
||||
<refsect1>
|
||||
<title>Notes</title>
|
||||
|
||||
<para>Functions described here are available as a
|
||||
<para>The functions described here are available as a
|
||||
shared library, which can be compiled and linked to with the
|
||||
<constant>libsystemd</constant> <citerefentry
|
||||
project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
|
||||
@ -47,7 +47,7 @@
|
||||
<refname>sd_event_prepare</refname>
|
||||
<refname>sd_event_dispatch</refname>
|
||||
|
||||
<refpurpose>Run parts of libsystemd event loop</refpurpose>
|
||||
<refpurpose>Run parts of the libsystemd event loop</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
@ -123,8 +123,8 @@
|
||||
└──────────┘
|
||||
</programlisting>
|
||||
|
||||
<para>All three functions as the first argument take the event
|
||||
loop object <parameter>event</parameter> that is created with with
|
||||
<para>All three functions take, as the first argument, the event
|
||||
loop object <parameter>event</parameter> that is created with
|
||||
<function>sd_event_new</function>. The timeout for
|
||||
<function>sd_event_wait</function> is specified with
|
||||
<parameter>timeout</parameter> in milliseconds.
|
||||
@ -138,11 +138,11 @@
|
||||
<para>On success, these functions return 0 or a positive integer.
|
||||
On failure, they return a negative errno-style error code. In case
|
||||
of <function>sd_event_prepare</function> and
|
||||
<function>sd_event_wait</function> a positive value means that
|
||||
<function>sd_event_wait</function>, a positive value means that
|
||||
events are ready to be processed and 0 means that no events are
|
||||
ready. In case of <function>sd_event_dispatch</function> a
|
||||
ready. In case of <function>sd_event_dispatch</function>, a
|
||||
positive value means that the loop is again in the initial state
|
||||
and 0 means the loop is finished. For any of those functions, a
|
||||
and 0 means the loop is finished. For any of these functions, a
|
||||
negative return value means the loop must be aborted.</para>
|
||||
</refsect1>
|
||||
|
||||
@ -155,7 +155,7 @@
|
||||
<varlistentry>
|
||||
<term><constant>-EINVAL</constant></term>
|
||||
|
||||
<listitem><para>Parameter <parameter>event</parameter> is
|
||||
<listitem><para>The <parameter>event</parameter> parameter is
|
||||
<constant>NULL</constant>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -182,7 +182,7 @@
|
||||
|
||||
</variablelist>
|
||||
|
||||
<para>Other errors are possible too.</para>
|
||||
<para>Other errors are possible, too.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
||||
@ -127,7 +127,7 @@
|
||||
<term><constant>-EINVAL</constant></term>
|
||||
|
||||
<listitem><para>An input parameter was invalid (out of range,
|
||||
or NULL, where that's not accepted).</para></listitem>
|
||||
or NULL, where that is not accepted).</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -89,7 +89,7 @@
|
||||
and
|
||||
<citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
|
||||
Matches are of the form <literal>FIELD=value</literal>, where the
|
||||
field part is a short uppercase string consisting only of 0-9, A-Z
|
||||
field part is a short uppercase string consisting only of 0–9, A–Z
|
||||
and the underscore. It may not begin with two underscores or be
|
||||
the empty string. The value part may be any value, including
|
||||
binary. If a match is applied, only entries with this field set
|
||||
|
||||
@ -113,7 +113,7 @@
|
||||
<function>sd_journal_get_data()</function> or
|
||||
<function>sd_journal_enumerate_data()</function>, or the read
|
||||
pointer is altered. Note that the data returned will be prefixed
|
||||
with the field name and '='. Also note that by default data fields
|
||||
with the field name and '='. Also note that, by default, data fields
|
||||
larger than 64K might get truncated to 64K. This threshold may be
|
||||
changed and turned off with
|
||||
<function>sd_journal_set_data_threshold()</function> (see
|
||||
|
||||
@ -187,7 +187,7 @@ else {
|
||||
certain latency. This call will return a positive value if the
|
||||
journal changes are detected immediately and zero when they need
|
||||
to be polled for and hence might be noticed only with a certain
|
||||
latency. Note that there's usually no need to invoke this function
|
||||
latency. Note that there is usually no need to invoke this function
|
||||
directly as <function>sd_journal_get_timeout()</function> on these
|
||||
file systems will ask for timeouts explicitly anyway.</para>
|
||||
</refsect1>
|
||||
|
||||
@ -100,8 +100,8 @@
|
||||
<para><function>sd_journal_open()</function> opens the log journal
|
||||
for reading. It will find all journal files automatically and
|
||||
interleave them automatically when reading. As first argument it
|
||||
takes a pointer to a <varname>sd_journal</varname> pointer, which
|
||||
on success will contain a journal context object. The second
|
||||
takes a pointer to a <varname>sd_journal</varname> pointer, which,
|
||||
on success, will contain a journal context object. The second
|
||||
argument is a flags field, which may consist of the following
|
||||
flags ORed together: <constant>SD_JOURNAL_LOCAL_ONLY</constant>
|
||||
makes sure only journal files generated on the local machine will
|
||||
|
||||
@ -134,8 +134,8 @@
|
||||
be ignored.) The value can be of any size and format. It is highly
|
||||
recommended to submit text strings formatted in the UTF-8
|
||||
character encoding only, and submit binary fields only when
|
||||
formatting in UTF-8 strings is not sensible. A number of well
|
||||
known fields are defined, see
|
||||
formatting in UTF-8 strings is not sensible. A number of
|
||||
well-known fields are defined, see
|
||||
<citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
for details, but additional application defined fields may be
|
||||
used. A variable may be assigned more than one value per
|
||||
@ -156,7 +156,7 @@
|
||||
<para><function>sd_journal_perror()</function> is a similar to
|
||||
<citerefentry project='die-net'><refentrytitle>perror</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
and writes a message to the journal that consists of the passed
|
||||
string, suffixed with ": " and a human readable representation of
|
||||
string, suffixed with ": " and a human-readable representation of
|
||||
the current error code stored in
|
||||
<citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
|
||||
If the message string is passed as <constant>NULL</constant> or
|
||||
|
||||
@ -76,7 +76,7 @@
|
||||
daemon to check for file descriptors passed by the service manager as
|
||||
part of the socket-based activation logic. It returns the number
|
||||
of received file descriptors. If no file descriptors have been
|
||||
received zero is returned. The first file descriptor may be found
|
||||
received, zero is returned. The first file descriptor may be found
|
||||
at file descriptor number 3
|
||||
(i.e. <constant>SD_LISTEN_FDS_START</constant>), the remaining
|
||||
descriptors follow at 4, 5, 6, ..., if any.</para>
|
||||
@ -104,7 +104,7 @@
|
||||
passed file descriptors to avoid further inheritance to children
|
||||
of the calling process.</para>
|
||||
|
||||
<para>If multiple socket units activate the same service the order
|
||||
<para>If multiple socket units activate the same service, the order
|
||||
of the file descriptors passed to its main process is undefined.
|
||||
If additional file descriptors have been passed to the service
|
||||
manager using
|
||||
@ -123,9 +123,9 @@
|
||||
variables are no longer inherited by child processes.</para>
|
||||
|
||||
<para><function>sd_listen_fds_with_names()</function> is like
|
||||
<function>sd_listen_fds()</function> but optionally also returns
|
||||
<function>sd_listen_fds()</function>, but optionally also returns
|
||||
an array of strings with identification names for the passed file
|
||||
descriptors, if that is available, and the
|
||||
descriptors, if that is available and the
|
||||
<parameter>names</parameter> parameter is non-NULL. This
|
||||
information is read from the <varname>$LISTEN_FDNAMES</varname>
|
||||
variable, which may contain a colon-separated list of names. For
|
||||
@ -134,7 +134,7 @@
|
||||
files, see
|
||||
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for details. For file descriptors pushed into the file descriptor
|
||||
store (see above) the name is set via the
|
||||
store (see above), the name is set via the
|
||||
<varname>FDNAME=</varname> field transmitted via
|
||||
<function>sd_pid_notify_with_fds()</function>. The primary usecase
|
||||
for these names are services which accept a variety of file
|
||||
@ -145,14 +145,14 @@
|
||||
<function>sd_is_socket()</function> and related calls is not
|
||||
sufficient. Note that the names used are not unique in any
|
||||
way. The returned array of strings has as many entries as file
|
||||
descriptors has been received, plus a final NULL pointer
|
||||
descriptors have been received, plus a final NULL pointer
|
||||
terminating the array. The caller needs to free the array itself
|
||||
and each of its elements with libc's <function>free()</function>
|
||||
call after use. If the <parameter>names</parameter> parameter is
|
||||
NULL the call is entirely equivalent to
|
||||
NULL, the call is entirely equivalent to
|
||||
<function>sd_listen_fds()</function>.</para>
|
||||
|
||||
<para>Under specific conditions the following automatic file
|
||||
<para>Under specific conditions, the following automatic file
|
||||
descriptor names are returned:
|
||||
|
||||
<table>
|
||||
|
||||
@ -214,7 +214,7 @@ else {
|
||||
<term><constant>-EINVAL</constant></term>
|
||||
|
||||
<listitem><para>An input parameter was invalid (out of range,
|
||||
or NULL, where that's not accepted). The specified category to
|
||||
or NULL, where that is not accepted). The specified category to
|
||||
watch is not known.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@ -116,7 +116,7 @@
|
||||
<term><constant>-EINVAL</constant></term>
|
||||
|
||||
<listitem><para>An input parameter was invalid (out of range,
|
||||
or NULL, where that's not accepted).</para></listitem>
|
||||
or NULL, where that is not accepted).</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -100,7 +100,7 @@
|
||||
<para><function>sd_notify()</function> may be called by a service
|
||||
to notify the service manager about state changes. It can be used
|
||||
to send arbitrary information, encoded in an
|
||||
environment-block-like string. Most importantly it can be used for
|
||||
environment-block-like string. Most importantly, it can be used for
|
||||
start-up completion notification.</para>
|
||||
|
||||
<para>If the <parameter>unset_environment</parameter> parameter is
|
||||
@ -158,7 +158,7 @@
|
||||
to the service manager that describes the service state. This
|
||||
is free-form and can be used for various purposes: general
|
||||
state feedback, fsck-like programs could pass completion
|
||||
percentages and failing programs could pass a human readable
|
||||
percentages and failing programs could pass a human-readable
|
||||
error message. Example: <literal>STATUS=Completed 66% of file
|
||||
system check...</literal></para></listitem>
|
||||
</varlistentry>
|
||||
@ -233,21 +233,21 @@
|
||||
<term>FDNAME=...</term>
|
||||
|
||||
<listitem><para>When used in combination with
|
||||
<varname>FDSTORE=1</varname> specifies a name for the
|
||||
<varname>FDSTORE=1</varname>, specifies a name for the
|
||||
submitted file descriptors. This name is passed to the service
|
||||
during activation, and may be queried using
|
||||
<citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>. File
|
||||
descriptors submitted without this field set, will implicitly
|
||||
get the name <literal>stored</literal> assigned. Note that if
|
||||
multiple file descriptors are submitted at once the specified
|
||||
get the name <literal>stored</literal> assigned. Note that, if
|
||||
multiple file descriptors are submitted at once, the specified
|
||||
name will be assigned to all of them. In order to assign
|
||||
different names to submitted file descriptors, submit them in
|
||||
seperate invocations of
|
||||
<function>sd_pid_notify_with_fds()</function>. The name may
|
||||
consist of any ASCII characters, but must not contain control
|
||||
consist of any ASCII character, but must not contain control
|
||||
characters or <literal>:</literal>. It may not be longer than
|
||||
255 characters. If a submitted name does not follow these
|
||||
restrictions it is ignored.</para></listitem>
|
||||
restrictions, it is ignored.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
@ -274,7 +274,7 @@
|
||||
use as originating PID for the message as first argument. This is
|
||||
useful to send notification messages on behalf of other processes,
|
||||
provided the appropriate privileges are available. If the PID
|
||||
argument is specified as 0 the process ID of the calling process
|
||||
argument is specified as 0, the process ID of the calling process
|
||||
is used, in which case the calls are fully equivalent to
|
||||
<function>sd_notify()</function> and
|
||||
<function>sd_notifyf()</function>.</para>
|
||||
@ -377,7 +377,7 @@
|
||||
|
||||
<para>To store an open file descriptor in the service manager,
|
||||
in order to continue operation after a service restart without
|
||||
losing state use <literal>FDSTORE=1</literal>:</para>
|
||||
losing state, use <literal>FDSTORE=1</literal>:</para>
|
||||
|
||||
<programlisting>sd_pid_notify_with_fds(0, 0, "FDSTORE=1\nFDNAME=foobar", &fd, 1);</programlisting>
|
||||
</example>
|
||||
|
||||
@ -176,7 +176,7 @@
|
||||
not all processes are part of a login session (e.g. system service
|
||||
processes, user processes that are shared between multiple
|
||||
sessions of the same user, or kernel threads). For processes not
|
||||
being part of a login session this function will fail with
|
||||
being part of a login session, this function will fail with
|
||||
-ENODATA. The returned string needs to be freed with the libc
|
||||
<citerefentry
|
||||
project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
@ -188,8 +188,8 @@
|
||||
unit name is a short string, suitable for usage in file system
|
||||
paths. Note that not all processes are part of a system
|
||||
unit/service (e.g. user processes, or kernel threads). For
|
||||
processes not being part of a systemd system unit this function
|
||||
will fail with -ENODATA (More specifically: this call will not
|
||||
processes not being part of a systemd system unit, this function
|
||||
will fail with -ENODATA. (More specifically, this call will not
|
||||
work for kernel threads.) The returned string needs to be freed
|
||||
with the libc <citerefentry
|
||||
project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
@ -198,17 +198,17 @@
|
||||
<para><function>sd_pid_get_user_unit()</function> may be used to
|
||||
determine the systemd user unit (i.e. user service or scope unit)
|
||||
identifier of a process identified by the specified PID. This is
|
||||
similar to <function>sd_pid_get_unit()</function> but applies to
|
||||
similar to <function>sd_pid_get_unit()</function>, but applies to
|
||||
user units instead of system units.</para>
|
||||
|
||||
<para><function>sd_pid_get_owner_uid()</function> may be used to
|
||||
determine the Unix UID (user identifier) of the owner of the
|
||||
session of a process identified the specified PID. Note that this
|
||||
function will succeed for user processes which are shared between
|
||||
multiple login sessions of the same user, where
|
||||
multiple login sessions of the same user, whereas
|
||||
<function>sd_pid_get_session()</function> will fail. For processes
|
||||
not being part of a login session and not being a shared process
|
||||
of a user this function will fail with -ENODATA.</para>
|
||||
of a user, this function will fail with -ENODATA.</para>
|
||||
|
||||
<para><function>sd_pid_get_machine_name()</function> may be used
|
||||
to determine the name of the VM or container is a member of. The
|
||||
@ -216,7 +216,7 @@
|
||||
paths. The returned string needs to be freed with the libc
|
||||
<citerefentry
|
||||
project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
call after use. For processes not part of a VM or containers this
|
||||
call after use. For processes not part of a VM or containers, this
|
||||
function fails with -ENODATA.</para>
|
||||
|
||||
<para><function>sd_pid_get_slice()</function> may be used to
|
||||
@ -227,7 +227,7 @@
|
||||
<citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
call after use.</para>
|
||||
|
||||
<para>Similar, <function>sd_pid_get_user_slice()</function>
|
||||
<para>Similarly, <function>sd_pid_get_user_slice()</function>
|
||||
returns the user slice (as managed by the user's systemd instance)
|
||||
of a process.</para>
|
||||
|
||||
@ -235,7 +235,7 @@
|
||||
group path of the specified process, relative to the root of the
|
||||
hierarchy. Returns the path without trailing slash, except for
|
||||
processes located in the root control group, where "/" is
|
||||
returned. To find the actual control group path in the file system
|
||||
returned. To find the actual control group path in the file system,
|
||||
the returned path needs to be prefixed with
|
||||
<filename>/sys/fs/cgroup/</filename> (if the unified control group
|
||||
setup is used), or
|
||||
@ -294,7 +294,7 @@
|
||||
<varlistentry>
|
||||
<term><constant>-ENODATA</constant></term>
|
||||
|
||||
<listitem><para>Given field is not specified for the described
|
||||
<listitem><para>The given field is not specified for the described
|
||||
process or peer.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -303,7 +303,7 @@
|
||||
<term><constant>-EINVAL</constant></term>
|
||||
|
||||
<listitem><para>An input parameter was invalid (out of range,
|
||||
or NULL, where that's not accepted).</para></listitem>
|
||||
or NULL, where that is not accepted).</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -158,7 +158,7 @@
|
||||
<varlistentry>
|
||||
<term><constant>-ENODATA</constant></term>
|
||||
|
||||
<listitem><para>Given field is not specified for the described
|
||||
<listitem><para>The given field is not specified for the described
|
||||
seat.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -174,7 +174,7 @@
|
||||
<term><constant>-EINVAL</constant></term>
|
||||
|
||||
<listitem><para>An input parameter was invalid (out of range,
|
||||
or NULL, where that's not accepted).</para></listitem>
|
||||
or NULL, where that is not accepted).</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -306,7 +306,7 @@
|
||||
<varlistentry>
|
||||
<term><constant>-ENODATA</constant></term>
|
||||
|
||||
<listitem><para>Given field is not specified for the described
|
||||
<listitem><para>The given field is not specified for the described
|
||||
session.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -315,7 +315,7 @@
|
||||
<term><constant>-EINVAL</constant></term>
|
||||
|
||||
<listitem><para>An input parameter was invalid (out of range,
|
||||
or NULL, where that's not accepted).</para></listitem>
|
||||
or NULL, where that is not accepted).</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -179,7 +179,7 @@
|
||||
<varlistentry>
|
||||
<term><constant>-ENODATA</constant></term>
|
||||
|
||||
<listitem><para>Given field is not specified for the described
|
||||
<listitem><para>The given field is not specified for the described
|
||||
user.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -195,7 +195,7 @@
|
||||
<term><constant>-EINVAL</constant></term>
|
||||
|
||||
<listitem><para>An input parameter was invalid (out of range,
|
||||
or NULL, where that's not accepted). This is also returned if
|
||||
or NULL, where that is not accepted). This is also returned if
|
||||
the passed user ID is 0xFFFF or 0xFFFFFFFF, which are
|
||||
undefined on Linux.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -157,7 +157,7 @@
|
||||
systemd-41.</para>
|
||||
|
||||
<para><function>sd_watchdog_enabled()</function> function was
|
||||
added in systemd-209. Since that version the
|
||||
added in systemd-209. Since that version, the
|
||||
<varname>$WATCHDOG_PID</varname> variable is also set.</para>
|
||||
</refsect1>
|
||||
|
||||
|
||||
@ -38,9 +38,9 @@
|
||||
<refsection id='main-conf'>
|
||||
<title>Configuration Directories and Precedence</title>
|
||||
|
||||
<para>Default configuration is defined during compilation, so a
|
||||
<para>The default configuration is defined during compilation, so a
|
||||
configuration file is only needed when it is necessary to deviate
|
||||
from those defaults. By default the configuration file in
|
||||
from those defaults. By default, the configuration file in
|
||||
<filename>/etc/systemd/</filename> contains commented out entries
|
||||
showing the defaults as a guide to the administrator. This file
|
||||
can be edited to create local overrides.
|
||||
|
||||
@ -140,10 +140,10 @@ net.bridge.bridge-nf-call-arptables = 0
|
||||
</programlisting>
|
||||
|
||||
<para>This method applies settings when the module is
|
||||
loaded. Please note that unless the <filename>br_netfilter</filename>
|
||||
loaded. Please note that, unless the <filename>br_netfilter</filename>
|
||||
module is loaded, bridged packets will not be filtered by
|
||||
netfilter (starting with kernel 3.18), so simply not loading the
|
||||
module is suffient to avoid filtering.</para>
|
||||
Netfilter (starting with kernel 3.18), so simply not loading the
|
||||
module is sufficient to avoid filtering.</para>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
@ -162,10 +162,10 @@ net.bridge.bridge-nf-call-arptables = 0
|
||||
</programlisting>
|
||||
|
||||
<para>This method forces the module to be always loaded. Please
|
||||
note that unless the <filename>br_netfilter</filename> module is
|
||||
loaded, bridged packets will not be filtered with netfilter
|
||||
note that, unless the <filename>br_netfilter</filename> module is
|
||||
loaded, bridged packets will not be filtered with Netfilter
|
||||
(starting with kernel 3.18), so simply not loading the module is
|
||||
suffient to avoid filtering.</para>
|
||||
sufficient to avoid filtering.</para>
|
||||
</example>
|
||||
</refsect1>
|
||||
|
||||
|
||||
@ -103,7 +103,7 @@
|
||||
<listitem>
|
||||
<para>The argument should be a comma-separated list of unit
|
||||
LOAD, SUB, or ACTIVE states. When listing units, show only
|
||||
those in specified states. Use <option>--state=failed</option>
|
||||
those in the specified states. Use <option>--state=failed</option>
|
||||
to show only failed units.</para>
|
||||
|
||||
<para>As a special case, if one of the arguments is
|
||||
@ -134,7 +134,7 @@
|
||||
|
||||
<para>Properties for units vary by unit type, so showing any
|
||||
unit (even a non-existent one) is a way to list properties
|
||||
pertaining to this type. Similarly showing any job will list
|
||||
pertaining to this type. Similarly, showing any job will list
|
||||
properties pertaining to all jobs. Properties for units are
|
||||
documented in
|
||||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||||
@ -359,7 +359,7 @@
|
||||
|
||||
<!-- we do not document -failed here, as it has been made
|
||||
redundant by -state=failed, which it predates. To keep
|
||||
things simple we only document the new switch, while
|
||||
things simple, we only document the new switch, while
|
||||
keeping the old one around for compatibility only. -->
|
||||
|
||||
<varlistentry>
|
||||
@ -458,7 +458,7 @@
|
||||
<listitem>
|
||||
<para>When used with <command>kill</command>, choose which
|
||||
signal to send to selected processes. Must be one of the
|
||||
well known signal specifiers such as <constant>SIGTERM</constant>, <constant>SIGINT</constant> or
|
||||
well-known signal specifiers such as <constant>SIGTERM</constant>, <constant>SIGINT</constant> or
|
||||
<constant>SIGSTOP</constant>. If omitted, defaults to
|
||||
<option>SIGTERM</option>.</para>
|
||||
</listitem>
|
||||
@ -518,7 +518,7 @@
|
||||
<listitem>
|
||||
<para>When used with
|
||||
<command>enable</command>/<command>disable</command>/<command>is-enabled</command>
|
||||
(and related commands), use alternative root path when
|
||||
(and related commands), use an alternate root path when
|
||||
looking for unit files.</para>
|
||||
</listitem>
|
||||
|
||||
@ -831,7 +831,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
|
||||
<para>This function is intended to generate human-readable
|
||||
output. If you are looking for computer-parsable output,
|
||||
use <command>show</command> instead. By default this
|
||||
use <command>show</command> instead. By default, this
|
||||
function only shows 10 lines of output and ellipsizes
|
||||
lines to fit in the terminal window. This can be changes
|
||||
with <option>--lines</option> and <option>--full</option>,
|
||||
@ -851,7 +851,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
<para>Show properties of one or more units, jobs, or the
|
||||
manager itself. If no argument is specified, properties of
|
||||
the manager will be shown. If a unit name is specified,
|
||||
properties of the unit is shown, and if a job id is
|
||||
properties of the unit is shown, and if a job ID is
|
||||
specified, properties of the job is shown. By default, empty
|
||||
properties are suppressed. Use <option>--all</option> to
|
||||
show those too. To select specific properties to show, use
|
||||
@ -983,7 +983,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
starting any of the units being enabled. If this
|
||||
is desired, either <option>--now</option> should be used
|
||||
together with this command, or an additional <command>start</command>
|
||||
command must be invoked for the unit. Also note that in case of
|
||||
command must be invoked for the unit. Also note that, in case of
|
||||
instance enablement, symlinks named the same as instances
|
||||
are created in the install location, however they all point to the
|
||||
same template unit file.</para>
|
||||
@ -1158,17 +1158,17 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>static</literal></entry>
|
||||
<entry>Unit file is not enabled, and has no provisions for enabling in the <literal>[Install]</literal> section.</entry>
|
||||
<entry>The unit file is not enabled, and has no provisions for enabling in the <literal>[Install]</literal> section.</entry>
|
||||
<entry>0</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>indirect</literal></entry>
|
||||
<entry>Unit file itself is not enabled, but it has a non-empty <varname>Also=</varname> setting in the <literal>[Install]</literal> section, listing other unit files that might be enabled.</entry>
|
||||
<entry>The unit file itself is not enabled, but it has a non-empty <varname>Also=</varname> setting in the <literal>[Install]</literal> section, listing other unit files that might be enabled.</entry>
|
||||
<entry>0</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>disabled</literal></entry>
|
||||
<entry>Unit file is not enabled.</entry>
|
||||
<entry>The unit file is not enabled.</entry>
|
||||
<entry>> 0</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -1227,12 +1227,12 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
|
||||
<listitem>
|
||||
<para>Adds <literal>Wants=</literal> or <literal>Requires=</literal>
|
||||
dependency, respectively, to the specified
|
||||
dependencies, respectively, to the specified
|
||||
<replaceable>TARGET</replaceable> for one or more units. </para>
|
||||
|
||||
<para>This command honors <option>--system</option>,
|
||||
<option>--user</option>, <option>--runtime</option> and
|
||||
<option>--global</option> in a similar way as
|
||||
<option>--global</option> in a way similar to
|
||||
<command>enable</command>.</para>
|
||||
|
||||
</listitem>
|
||||
@ -1248,8 +1248,8 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
|
||||
<para>Depending on whether <option>--system</option> (the default),
|
||||
<option>--user</option>, or <option>--global</option> is specified,
|
||||
this creates a drop-in file for each unit either for the system,
|
||||
for the calling user or for all futures logins of all users. Then,
|
||||
this command creates a drop-in file for each unit either for the system,
|
||||
for the calling user, or for all futures logins of all users. Then,
|
||||
the editor (see the "Environment" section below) is invoked on
|
||||
temporary files which will be written to the real location if the
|
||||
editor exits successfully.</para>
|
||||
@ -1261,8 +1261,8 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
be made temporarily in <filename>/run</filename> and they will be
|
||||
lost on the next reboot.</para>
|
||||
|
||||
<para>If the temporary file is empty upon exit the modification of
|
||||
the related unit is canceled</para>
|
||||
<para>If the temporary file is empty upon exit, the modification of
|
||||
the related unit is canceled.</para>
|
||||
|
||||
<para>After the units have been edited, systemd configuration is
|
||||
reloaded (in a way that is equivalent to <command>daemon-reload</command>).
|
||||
@ -1270,7 +1270,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
|
||||
<para>Note that this command cannot be used to remotely edit units
|
||||
and that you cannot temporarily edit units which are in
|
||||
<filename>/etc</filename> since they take precedence over
|
||||
<filename>/etc</filename>, since they take precedence over
|
||||
<filename>/run</filename>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -1442,7 +1442,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
<term><command>daemon-reload</command></term>
|
||||
|
||||
<listitem>
|
||||
<para>Reload systemd manager configuration. This will
|
||||
<para>Reload the systemd manager configuration. This will
|
||||
rerun all generators (see
|
||||
<citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
|
||||
reload all unit files, and recreate the entire dependency
|
||||
@ -1485,7 +1485,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
maintenance mode, and with no failed services. Failure is
|
||||
returned otherwise (exit code non-zero). In addition, the
|
||||
current state is printed in a short string to standard
|
||||
output, see table below. Use <option>--quiet</option> to
|
||||
output, see the table below. Use <option>--quiet</option> to
|
||||
suppress this output.</para>
|
||||
|
||||
<table>
|
||||
@ -1684,7 +1684,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
<para>Switches to a different root directory and executes a
|
||||
new system manager process below it. This is intended for
|
||||
usage in initial RAM disks ("initrd"), and will transition
|
||||
from the initrd's system manager process (a.k.a "init"
|
||||
from the initrd's system manager process (a.k.a. "init"
|
||||
process) to the main system manager process. This call takes two
|
||||
arguments: the directory that is to become the new root directory, and
|
||||
the path to the new system manager binary below it to
|
||||
|
||||
@ -61,7 +61,7 @@
|
||||
<title>Description</title>
|
||||
|
||||
<para><command>systemd-activate</command> can be used to
|
||||
launch a socket activated daemon from the command line for
|
||||
launch a socket-activated daemon from the command line for
|
||||
testing purposes. It can also be used to launch single instances
|
||||
of the daemon per connection (inetd-style).
|
||||
</para>
|
||||
@ -164,7 +164,7 @@
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>Run a socket activated instance of <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
|
||||
<title>Run a socket-activated instance of <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
|
||||
|
||||
<programlisting>$ /usr/lib/systemd/systemd-activate -l 19531 /usr/lib/systemd/systemd-journal-gatewayd</programlisting>
|
||||
</example>
|
||||
|
||||
@ -178,7 +178,7 @@
|
||||
<replaceable>TARGET</replaceable></command> changes the current log
|
||||
target of the <command>systemd</command> daemon to
|
||||
<replaceable>TARGET</replaceable> (accepts the same values as
|
||||
<option>--log-target=</option> described in
|
||||
<option>--log-target=</option>, described in
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).</para>
|
||||
|
||||
<para><command>systemd-analyze verify</command> will load unit
|
||||
|
||||
@ -138,9 +138,9 @@
|
||||
cache for the password. If set, then the tool will try to push
|
||||
any collected passwords into the kernel keyring of the root
|
||||
user, as a key of the specified name. If combined with
|
||||
<option>--accept-cached</option> it will also try to retrieve
|
||||
the such cached passwords from the key in the kernel keyring
|
||||
instead of querying the user right-away. By using this option
|
||||
<option>--accept-cached</option>, it will also try to retrieve
|
||||
such cached passwords from the key in the kernel keyring
|
||||
instead of querying the user right away. By using this option,
|
||||
the kernel keyring may be used as effective cache to avoid
|
||||
repeatedly asking users for passwords, if there are multiple
|
||||
objects that may be unlocked with the same password. The
|
||||
@ -181,7 +181,7 @@
|
||||
<term><option>--accept-cached</option></term>
|
||||
|
||||
<listitem><para>If passed, accept cached passwords, i.e.
|
||||
passwords previously typed in. </para></listitem>
|
||||
passwords previously entered.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -58,8 +58,8 @@
|
||||
that restores the display backlight brightness at early boot and
|
||||
saves it at shutdown. On disk, the backlight brightness is stored
|
||||
in <filename>/var/lib/systemd/backlight/</filename>. During
|
||||
loading, if udev property <option>ID_BACKLIGHT_CLAMP</option> is
|
||||
not set to false value, the brightness is clamped to a value of at
|
||||
loading, if the udev property <option>ID_BACKLIGHT_CLAMP</option> is
|
||||
not set to false, the brightness is clamped to a value of at
|
||||
least 1 or 5% of maximum brightness, whichever is greater. This
|
||||
restriction will be removed when the kernel allows user space to
|
||||
reliably set a brightness value which does not turn off the
|
||||
|
||||
@ -54,7 +54,7 @@
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para><filename>systemd-binfmt.service</filename> is an early-boot
|
||||
<para><filename>systemd-binfmt.service</filename> is an early boot
|
||||
service that registers additional binary formats for executables
|
||||
in the kernel.</para>
|
||||
|
||||
|
||||
@ -66,7 +66,7 @@
|
||||
and logging startup information in the background.
|
||||
</para>
|
||||
<para>
|
||||
After collecting a certain amount of data (usually 15-30
|
||||
After collecting a certain amount of data (usually 15–30
|
||||
seconds, default 20 s) the logging stops and a graph is
|
||||
generated from the logged information. This graph contains vital
|
||||
clues as to which resources are being used, in which order, and
|
||||
@ -114,7 +114,7 @@
|
||||
<term><emphasis>Started as a standalone program</emphasis></term>
|
||||
<listitem><para>One can execute
|
||||
<command>systemd-bootchart</command> as normal application
|
||||
from the command line. In this mode it is highly recommended
|
||||
from the command line. In this mode, it is highly recommended
|
||||
to pass the <option>-r</option> flag in order to not graph the
|
||||
time elapsed since boot and before systemd-bootchart was
|
||||
started, as it may result in extremely large graphs. The time
|
||||
@ -149,7 +149,7 @@
|
||||
<term><option>--freq <replaceable>f</replaceable></option></term>
|
||||
<listitem><para>Specify the sample log frequency, a positive
|
||||
real <replaceable>f</replaceable>, in Hz. Most systems can
|
||||
cope with values up to 25-50 without creating too much
|
||||
cope with values up to 25–50 without creating too much
|
||||
overhead.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@ -112,7 +112,7 @@
|
||||
<citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
|
||||
Defaults to <literal>info</literal>. Note that this simply
|
||||
controls the default, individual lines may be logged with
|
||||
different levels if they are prefixed accordingly. For details
|
||||
different levels if they are prefixed accordingly. For details,
|
||||
see <option>--level-prefix=</option> below.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@ -154,7 +154,7 @@
|
||||
<term><option>-r</option></term>
|
||||
<term><option>--raw</option></term>
|
||||
|
||||
<listitem><para>Format byte counts (as in memory usage and IO metrics)
|
||||
<listitem><para>Format byte counts (as in memory usage and I/O metrics)
|
||||
with raw numeric values rather than human-readable
|
||||
numbers.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -164,7 +164,7 @@
|
||||
<term><option>--cpu=time</option></term>
|
||||
|
||||
<listitem><para>Controls whether the CPU usage is shown as
|
||||
percentage or time. By default the CPU usage is shown as
|
||||
percentage or time. By default, the CPU usage is shown as
|
||||
percentage. This setting may also be toggled at runtime by
|
||||
pressing the <keycap>%</keycap> key.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -173,8 +173,8 @@
|
||||
<term><option>-P</option></term>
|
||||
|
||||
<listitem><para>Count only userspace processes instead of all
|
||||
tasks. By default all tasks are counted: each kernel thread
|
||||
and each userspace thread individually. With this setting
|
||||
tasks. By default, all tasks are counted: each kernel thread
|
||||
and each userspace thread individually. With this setting,
|
||||
kernel threads are excluded from the counting and each
|
||||
userspace process only counts as one, regardless how many
|
||||
threads it consists of. This setting may also be toggled at
|
||||
@ -187,9 +187,9 @@
|
||||
<term><option>-k</option></term>
|
||||
|
||||
<listitem><para>Count only userspace processes and kernel
|
||||
threads instead of all tasks. By default all tasks are
|
||||
threads instead of all tasks. By default, all tasks are
|
||||
counted: each kernel thread and each userspace thread
|
||||
individually. With this setting kernel threads are included in
|
||||
individually. With this setting, kernel threads are included in
|
||||
the counting and each userspace process only counts as on one,
|
||||
regardless how many threads it consists of. This setting may
|
||||
also be toggled at runtime by pressing the <keycap>k</keycap>
|
||||
@ -203,9 +203,9 @@
|
||||
<listitem><para>Controls whether the number of processes shown
|
||||
for a control group shall include all processes that are
|
||||
contained in any of the child control groups as well. Takes a
|
||||
boolean argument, defaults to <literal>yes</literal>. If
|
||||
enabled the processes in child control groups are included, if
|
||||
disabled only the processes in the control group itself are
|
||||
boolean argument, which defaults to <literal>yes</literal>. If
|
||||
enabled, the processes in child control groups are included, if
|
||||
disabled, only the processes in the control group itself are
|
||||
counted. This setting may also be toggled at runtime by
|
||||
pressing the <keycap>r</keycap> key. Note that this setting
|
||||
only applies to process counting, i.e. when the
|
||||
@ -294,7 +294,7 @@
|
||||
<term><keycap>i</keycap></term>
|
||||
|
||||
<listitem><para>Sort the control groups by path, number of
|
||||
tasks, CPU load, memory usage, or IO load, respectively. This
|
||||
tasks, CPU load, memory usage, or I/O load, respectively. This
|
||||
setting may also be controlled using the
|
||||
<option>--order=</option> command line
|
||||
switch.</para></listitem>
|
||||
@ -343,7 +343,7 @@
|
||||
excluding processes in child control groups in control group
|
||||
process counts. This setting may also be controlled using the
|
||||
<option>--recursive=</option> command line switch. This key is
|
||||
not available of all tasks are counted, it is only available
|
||||
not available if all tasks are counted, it is only available
|
||||
if processes are counted, as enabled with the
|
||||
<keycap>P</keycap> or <keycap>k</keycap>
|
||||
keys.</para></listitem>
|
||||
|
||||
@ -72,7 +72,7 @@
|
||||
in <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
||||
In particular, the coredump will only be processed when the
|
||||
related resource limits are high enough. For programs started by
|
||||
<command>systemd</command> those may be set using
|
||||
<command>systemd</command>, those may be set using
|
||||
<varname>LimitCore=</varname> (see
|
||||
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
|
||||
</para>
|
||||
|
||||
@ -111,7 +111,7 @@
|
||||
system and the initrd.</para>
|
||||
<para>If /etc/crypttab contains entries with the same UUID,
|
||||
then the name, keyfile and options specified there will be
|
||||
used. Otherwise the device will have the name
|
||||
used. Otherwise, the device will have the name
|
||||
<literal>luks-UUID</literal>.</para>
|
||||
<para>If /etc/crypttab exists, only those UUIDs
|
||||
specified on the kernel command line
|
||||
|
||||
@ -70,7 +70,7 @@
|
||||
directories which contain "drop-in" files with configuration
|
||||
snippets which augment the main configuration file. "Drop-in"
|
||||
files can be overridden in the same way by placing files with the
|
||||
same name in a directory of higher priority (except that in case
|
||||
same name in a directory of higher priority (except that, in case
|
||||
of "drop-in" files, both the "drop-in" file name and the name of
|
||||
the containing directory, which corresponds to the name of the
|
||||
main configuration file, must match). For a fuller explanation,
|
||||
|
||||
@ -62,7 +62,7 @@
|
||||
technology and can distinguish full VM virtualization from
|
||||
container virtualization. <filename>systemd-detect-virt</filename>
|
||||
exits with a return value of 0 (success) if a virtualization
|
||||
technology is detected, and non-zero (error) otherwise. By default
|
||||
technology is detected, and non-zero (error) otherwise. By default,
|
||||
any type of virtualization is detected, and the options
|
||||
<option>--container</option> and <option>--vm</option> can be used
|
||||
to limit what types of virtualization are detected.</para>
|
||||
@ -207,7 +207,7 @@
|
||||
|
||||
<listitem><para>Detect whether invoked in a
|
||||
<citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
||||
environment. In this mode no output is written, but the return
|
||||
environment. In this mode, no output is written, but the return
|
||||
value indicates whether the process was invoked in a
|
||||
<function>chroot()</function>
|
||||
environment or not.</para></listitem>
|
||||
|
||||
@ -67,11 +67,11 @@
|
||||
and will process them individually, one after the other. It will
|
||||
output them separated by spaces to stdout.</para>
|
||||
|
||||
<para>By default this command will escape the strings passed,
|
||||
<para>By default, this command will escape the strings passed,
|
||||
unless <option>--unescape</option> is passed which results in the
|
||||
inverse operation being applied. If <option>--mangle</option> a
|
||||
special mode of escaping is applied instead, which assumes a
|
||||
string to be already escaped but will escape everything that
|
||||
inverse operation being applied. If <option>--mangle</option> is given, a
|
||||
special mode of escaping is applied instead, which assumes the
|
||||
string is already escaped but will escape everything that
|
||||
appears obviously non-escaped.</para>
|
||||
</refsect1>
|
||||
|
||||
|
||||
@ -80,12 +80,12 @@
|
||||
<listitem><para>The root user's password</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Each of the fields may either be queried interactively from
|
||||
the users, set non-interactively on the tool's command line, or be
|
||||
<para>Each of the fields may either be queried interactively by
|
||||
users, set non-interactively on the tool's command line, or be
|
||||
copied from a host system that is used to set up the system
|
||||
image.</para>
|
||||
|
||||
<para>If a setting is already initialized it will not be
|
||||
<para>If a setting is already initialized, it will not be
|
||||
overwritten and the user will not be prompted for the
|
||||
setting.</para>
|
||||
|
||||
@ -166,10 +166,10 @@
|
||||
<citerefentry project='die-net'><refentrytitle>shadow</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
file. This setting exists in two forms:
|
||||
<option>--root-password=</option> accepts the password to set
|
||||
directly on the command line,
|
||||
directly on the command line, and
|
||||
<option>--root-password-file=</option> reads it from a file.
|
||||
Note that it is not recommended specifying passwords on the
|
||||
command line as other users might be able to see them simply
|
||||
Note that it is not recommended to specify passwords on the
|
||||
command line, as other users might be able to see them simply
|
||||
by invoking
|
||||
<citerefentry project='die-net'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -62,15 +62,15 @@
|
||||
device that is configured for file system checking.
|
||||
<filename>systemd-fsck-root.service</filename> is responsible for
|
||||
file system checks on the root file system, but only if the
|
||||
root filesystem wasn't checked in the initramfs.
|
||||
root filesystem was not checked in the initramfs.
|
||||
<filename>systemd-fsck@.service</filename> is used for all other
|
||||
file systems and for the root file system in the initramfs.</para>
|
||||
|
||||
<para>Those services are started at boot if
|
||||
<para>These services are started at boot if
|
||||
<option>passno</option> in <filename>/etc/fstab</filename> for the
|
||||
file system is set to a value greater than zero. The file system
|
||||
check for root is performed before the other file systems. Other
|
||||
file systems may be checked in parallel, except when they are one
|
||||
file systems may be checked in parallel, except when they are on
|
||||
the same rotating disk.</para>
|
||||
|
||||
<para><filename>systemd-fsck</filename> does not know any details
|
||||
|
||||
@ -126,7 +126,7 @@
|
||||
<varname>mount.usr=</varname> will default to the value set in
|
||||
<varname>root=</varname>.</para>
|
||||
|
||||
<para>Otherwise this parameter defaults to the
|
||||
<para>Otherwise, this parameter defaults to the
|
||||
<filename>/usr</filename> entry found in
|
||||
<filename>/etc/fstab</filename> on the root filesystem.</para>
|
||||
|
||||
@ -143,7 +143,7 @@
|
||||
<varname>mount.usrfstype=</varname> will default to the value
|
||||
set in <varname>rootfstype=</varname>.</para>
|
||||
|
||||
<para>Otherwise this value will be read from the
|
||||
<para>Otherwise, this value will be read from the
|
||||
<filename>/usr</filename> entry in
|
||||
<filename>/etc/fstab</filename> on the root filesystem.</para>
|
||||
|
||||
@ -159,7 +159,7 @@
|
||||
<varname>mount.usrflags=</varname> will default to the value
|
||||
set in <varname>rootflags=</varname>.</para>
|
||||
|
||||
<para>Otherwise this value will be read from the
|
||||
<para>Otherwise, this value will be read from the
|
||||
<filename>/usr</filename> entry in
|
||||
<filename>/etc/fstab</filename> on the root filesystem.</para>
|
||||
|
||||
|
||||
@ -142,7 +142,7 @@
|
||||
</table>
|
||||
|
||||
<para>The <filename>/home</filename> and <filename>/srv</filename>
|
||||
partitions may be encrypted in LUKS format. In this case a device
|
||||
partitions may be encrypted in LUKS format. In this case, a device
|
||||
mapper device is set up under the names
|
||||
<filename>/dev/mapper/home</filename> and
|
||||
<filename>/dev/mapper/srv</filename>. Note that this might create
|
||||
@ -151,8 +151,8 @@
|
||||
device name.</para>
|
||||
|
||||
<para>Mount and automount units for the EFI System Partition (ESP),
|
||||
mounting it to <filename>/boot</filename> are generated on EFI
|
||||
systems, where the boot loader communicates the used ESP to the operating
|
||||
mounting it to <filename>/boot</filename>, are generated on EFI
|
||||
systems where the boot loader communicates the used ESP to the operating
|
||||
system. Since this generator creates an automount unit, the mount will
|
||||
only be activated on-demand, when accessed. On systems where
|
||||
<filename>/boot</filename> is an explicitly configured mount
|
||||
|
||||
@ -64,7 +64,7 @@
|
||||
<term><option>-r</option></term>
|
||||
<term><option>--root=<replaceable>PATH</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>Alternative root path in the filesystem.</para>
|
||||
<para>Alternate root path in the filesystem.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
@ -196,7 +196,7 @@
|
||||
<programlisting>openssl req -newkey rsa:2048 -days 3650 -x509 -nodes \
|
||||
-out ca.pem -keyout ca.key -subj '/CN=Certificate authority/'
|
||||
|
||||
cat >ca.conf <<EOF
|
||||
cat >ca.conf <<EOF
|
||||
[ ca ]
|
||||
default_ca = this
|
||||
|
||||
@ -221,7 +221,7 @@ emailAddress = optional
|
||||
EOF
|
||||
|
||||
touch index
|
||||
echo 0001 > serial
|
||||
echo 0001 >serial
|
||||
|
||||
SERVER=server
|
||||
CLIENT=client
|
||||
@ -244,7 +244,7 @@ openssl ca -batch -config ca.conf -notext -in $CLIENT.csr -out $CLIENT.pem
|
||||
<varname>ServerCertificateFile=</varname>,
|
||||
<varname>ServerKeyFile=</varname>, in
|
||||
<filename>/etc/systemd/journal-remote.conf</filename> and
|
||||
<filename>/etc/systemd/journal-upload.conf</filename>
|
||||
<filename>/etc/systemd/journal-upload.conf</filename>,
|
||||
respectively. The default locations can be queried by using
|
||||
<command>systemd-journal-remote --help</command> and
|
||||
<command>systemd-journal-upload --help</command>.</para>
|
||||
|
||||
@ -244,7 +244,7 @@ systemd-tmpfiles --create --prefix /var/log/journal</programlisting>
|
||||
|
||||
<listitem><para>Sockets and other paths that
|
||||
<command>systemd-journald</command> will listen on that are
|
||||
visible in the file system. In addition to those, journald can
|
||||
visible in the file system. In addition to these, journald can
|
||||
listen for audit events using netlink.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
@ -42,7 +42,7 @@
|
||||
|
||||
<refnamediv>
|
||||
<refname>systemd-machine-id-commit.service</refname>
|
||||
<refpurpose>Commit a transient machine-id to disk</refpurpose>
|
||||
<refpurpose>Commit a transient machine ID to disk</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
@ -53,7 +53,7 @@
|
||||
<title>Description</title>
|
||||
|
||||
<para><filename>systemd-machine-id-commit.service</filename> is an
|
||||
early-boot service responsible for committing transient
|
||||
early boot service responsible for committing transient
|
||||
<filename>/etc/machine-id</filename> files to a writable disk file
|
||||
system. See
|
||||
<citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
@ -74,7 +74,7 @@
|
||||
|
||||
<para>The main use case of this service are systems where
|
||||
<filename>/etc/machine-id</filename> is read-only and initially
|
||||
not initialized. In this case the system manager will generate a
|
||||
not initialized. In this case, the system manager will generate a
|
||||
transient machine ID file on a memory file system, and mount it
|
||||
over <filename>/etc/machine-id</filename>, during the early boot
|
||||
phase. This service is then invoked in a later boot phase, as soon
|
||||
|
||||
@ -71,7 +71,7 @@
|
||||
for more information about this file.</para>
|
||||
|
||||
<para>If the tool is invoked without the <option>--commit</option>
|
||||
switch <filename>/etc/machine-id</filename> is initialized with a
|
||||
switch, <filename>/etc/machine-id</filename> is initialized with a
|
||||
valid, new machined ID if it is missing or empty. The new machine
|
||||
ID will be acquired in the following fashion:</para>
|
||||
|
||||
@ -88,14 +88,14 @@
|
||||
and is different for every booted instance of the
|
||||
VM.</para></listitem>
|
||||
|
||||
<listitem><para>Similar, if run inside a Linux container
|
||||
environment and a UUID is configured for the container this is
|
||||
used to initialize the machine ID. For details see the
|
||||
<listitem><para>Similarly, if run inside a Linux container
|
||||
environment and a UUID is configured for the container, this is
|
||||
used to initialize the machine ID. For details, see the
|
||||
documentation of the <ulink
|
||||
url="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container
|
||||
Interface</ulink>.</para></listitem>
|
||||
|
||||
<listitem><para>Otherwise a new ID is randomly
|
||||
<listitem><para>Otherwise, a new ID is randomly
|
||||
generated.</para></listitem>
|
||||
</orderedlist>
|
||||
|
||||
@ -148,7 +148,7 @@
|
||||
|
||||
<para>This command is primarily used by the
|
||||
<citerefentry><refentrytitle>systemd-machine-id-commit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
early-boot service.</para></listitem>
|
||||
early boot service.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<xi:include href="standard-options.xml" xpointer="help" />
|
||||
|
||||
@ -55,7 +55,7 @@
|
||||
<title>Description</title>
|
||||
|
||||
<para><filename>systemd-modules-load.service</filename> is an
|
||||
early-boot service that loads kernel modules based on static
|
||||
early boot service that loads kernel modules based on static
|
||||
configuration.</para>
|
||||
|
||||
<para>See
|
||||
|
||||
@ -86,7 +86,7 @@
|
||||
<varlistentry>
|
||||
<term><option>--ignore=</option></term>
|
||||
<listitem><para>Network interfaces to be ignored when deciding
|
||||
if the system is online. By default only the loopback
|
||||
if the system is online. By default, only the loopback
|
||||
interface is ignored. This option may be used more than once
|
||||
to ignore multiple network interfaces. </para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -60,7 +60,7 @@
|
||||
<para><command>systemd-notify</command> may be called by daemon
|
||||
scripts to notify the init system about status changes. It can be
|
||||
used to send arbitrary information, encoded in an
|
||||
environment-block-like list of strings. Most importantly it can be
|
||||
environment-block-like list of strings. Most importantly, it can be
|
||||
used for start-up completion notification.</para>
|
||||
|
||||
<para>This is mostly just a wrapper around
|
||||
@ -125,7 +125,7 @@
|
||||
message is sent. This option is hence unrelated to the other
|
||||
options. For details about the semantics of this option, see
|
||||
<citerefentry><refentrytitle>sd_booted</refentrytitle><manvolnum>3</manvolnum></citerefentry>. An
|
||||
alternative way to check for this state is to call
|
||||
alternate way to check for this state is to call
|
||||
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
with the <command>is-system-running</command> command. It will
|
||||
return <literal>offline</literal> if the system was not booted
|
||||
|
||||
@ -325,7 +325,7 @@
|
||||
<varlistentry>
|
||||
<term><option>--private-users=</option></term>
|
||||
|
||||
<listitem><para>Enables user namespacing. If enabled the
|
||||
<listitem><para>Enables user namespacing. If enabled, the
|
||||
container will run with its own private set of Unix user and
|
||||
group ids (UIDs and GIDs). Takes none, one or two
|
||||
colon-separated parameters: the first parameter specifies the
|
||||
@ -335,7 +335,7 @@
|
||||
assigned. If the first parameter is also omitted (and hence
|
||||
no parameter passed at all), the first UID assigned to the
|
||||
container is read from the owner of the root directory of the
|
||||
container's directory tree. By default no user namespacing is
|
||||
container's directory tree. By default, no user namespacing is
|
||||
applied.</para>
|
||||
|
||||
<para>Note that user namespacing currently requires OS trees
|
||||
@ -344,15 +344,15 @@
|
||||
must be shifted to the container UID base that is
|
||||
used during container runtime.</para>
|
||||
|
||||
<para>It is recommended to assign as least 65536 UIDs to each
|
||||
<para>It is recommended to assign at least 65536 UIDs to each
|
||||
container, so that the usable UID range in the container
|
||||
covers 16bit. For best security do not assign overlapping UID
|
||||
covers 16 bit. For best security, do not assign overlapping UID
|
||||
ranges to multiple containers. It is hence a good idea to use
|
||||
the upper 16bit of the host 32bit UIDs as container
|
||||
identifier, while the lower 16bit encode the container UID
|
||||
the upper 16 bit of the host 32-bit UIDs as container
|
||||
identifier, while the lower 16 bit encode the container UID
|
||||
used.</para>
|
||||
|
||||
<para>When user namespaces are used the GID range assigned to
|
||||
<para>When user namespaces are used, the GID range assigned to
|
||||
each container is always chosen identical to the UID
|
||||
range.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -458,7 +458,7 @@
|
||||
which case <literal>tcp</literal> is assumed. The container
|
||||
port number and its colon may be omitted, in which case the
|
||||
same port as the host port is implied. This option is only
|
||||
supported if private networking is used, such as
|
||||
supported if private networking is used, such as with
|
||||
<option>--network-veth</option> or
|
||||
<option>--network-bridge=</option>.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -575,15 +575,15 @@
|
||||
<term><option>--bind-ro=</option></term>
|
||||
|
||||
<listitem><para>Bind mount a file or directory from the host
|
||||
into the container. Takes one of: a path argument -- in which
|
||||
into the container. Takes one of: a path argument — in which
|
||||
case the specified path will be mounted from the host to the
|
||||
same path in the container --, or a colon-separated pair of
|
||||
paths -- in which case the first specified path is the source
|
||||
same path in the container —, or a colon-separated pair of
|
||||
paths — in which case the first specified path is the source
|
||||
in the host, and the second path is the destination in the
|
||||
container --, or a colon-separated triple of source path,
|
||||
destination path and mount options. Mount options are comma
|
||||
separated and currently only "rbind" and "norbind"
|
||||
are allowed. Defaults to "rbind". Backslash escapes are interpreted so
|
||||
container —, or a colon-separated triple of source path,
|
||||
destination path and mount options. Mount options are
|
||||
comma-separated and currently, only "rbind" and "norbind"
|
||||
are allowed. Defaults to "rbind". Backslash escapes are interpreted, so
|
||||
<literal>\:</literal> may be used to embed colons in either path.
|
||||
This option may be specified multiple times for
|
||||
creating multiple independent bind mount points. The
|
||||
@ -599,13 +599,13 @@
|
||||
mount the tmpfs instance to (in which case the directory
|
||||
access mode will be chosen as 0755, owned by root/root), or
|
||||
optionally a colon-separated pair of path and mount option
|
||||
string, that is used for mounting (in which case the kernel
|
||||
string that is used for mounting (in which case the kernel
|
||||
default for access mode and owner will be chosen, unless
|
||||
otherwise specified). This option is particularly useful for
|
||||
mounting directories such as <filename>/var</filename> as
|
||||
tmpfs, to allow state-less systems, in particular when
|
||||
combined with <option>--read-only</option>.
|
||||
Backslash escapes are interpreted in the path so
|
||||
Backslash escapes are interpreted in the path, so
|
||||
<literal>\:</literal> may be used to embed colons in the path.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
@ -630,9 +630,9 @@
|
||||
overlay file system. The left-most path is hence the lowest
|
||||
directory tree, the second-to-last path the highest directory
|
||||
tree in the stacking order. If <option>--overlay-ro=</option>
|
||||
is used instead of <option>--overlay=</option> a read-only
|
||||
is used instead of <option>--overlay=</option>, a read-only
|
||||
overlay file system is created. If a writable overlay file
|
||||
system is created all changes made to it are written to the
|
||||
system is created, all changes made to it are written to the
|
||||
highest directory tree in the stacking order, i.e. the
|
||||
second-to-last specified.</para>
|
||||
|
||||
@ -693,7 +693,7 @@
|
||||
<listitem><para>Controls whether the container is registered
|
||||
with
|
||||
<citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
|
||||
Takes a boolean argument, defaults to <literal>yes</literal>.
|
||||
Takes a boolean argument, which defaults to <literal>yes</literal>.
|
||||
This option should be enabled when the container runs a full
|
||||
Operating System (more specifically: an init system), and is
|
||||
useful to ensure that the container is accessible via
|
||||
@ -752,20 +752,20 @@
|
||||
|
||||
<listitem><para>Boots the container in volatile mode. When no
|
||||
mode parameter is passed or when mode is specified as
|
||||
<option>yes</option> full volatile mode is enabled. This
|
||||
means the root directory is mounted as mostly unpopulated
|
||||
<option>yes</option>, full volatile mode is enabled. This
|
||||
means the root directory is mounted as a mostly unpopulated
|
||||
<literal>tmpfs</literal> instance, and
|
||||
<filename>/usr</filename> from the OS tree is mounted into it,
|
||||
read-only (the system thus starts up with read-only OS
|
||||
resources, but pristine state and configuration, any changes
|
||||
to the either are lost on shutdown). When the mode parameter
|
||||
is specified as <option>state</option> the OS tree is
|
||||
is specified as <option>state</option>, the OS tree is
|
||||
mounted read-only, but <filename>/var</filename> is mounted as
|
||||
<literal>tmpfs</literal> instance into it (the system thus
|
||||
a <literal>tmpfs</literal> instance into it (the system thus
|
||||
starts up with read-only OS resources and configuration, but
|
||||
pristine state, any changes to the latter are lost on
|
||||
pristine state, and any changes to the latter are lost on
|
||||
shutdown). When the mode parameter is specified as
|
||||
<option>no</option> (the default) the whole OS tree is made
|
||||
<option>no</option> (the default), the whole OS tree is made
|
||||
available writable.</para>
|
||||
|
||||
<para>Note that setting this to <option>yes</option> or
|
||||
@ -786,43 +786,43 @@
|
||||
special values <option>override</option> or
|
||||
<option>trusted</option>.</para>
|
||||
|
||||
<para>If enabled (the default) a settings file named after the
|
||||
<para>If enabled (the default), a settings file named after the
|
||||
machine (as specified with the <option>--machine=</option>
|
||||
setting, or derived from the directory or image file name)
|
||||
with the suffix <filename>.nspawn</filename> is searched in
|
||||
<filename>/etc/systemd/nspawn/</filename> and
|
||||
<filename>/run/systemd/nspawn/</filename>. If it is found
|
||||
there, its settings are read and used. If it is not found
|
||||
there it is subsequently searched in the same directory as the
|
||||
there, it is subsequently searched in the same directory as the
|
||||
image file or in the immediate parent of the root directory of
|
||||
the container. In this case, if the file is found its settings
|
||||
the container. In this case, if the file is found, its settings
|
||||
will be also read and used, but potentially unsafe settings
|
||||
are ignored. Note that in both these cases settings on the
|
||||
are ignored. Note that in both these cases, settings on the
|
||||
command line take precedence over the corresponding settings
|
||||
from loaded <filename>.nspawn</filename> files, if both are
|
||||
specified. Unsafe settings are considered all settings that
|
||||
elevate the container's privileges or grant access to
|
||||
additional resources such as files or directories of the
|
||||
host. For details about the format and contents of
|
||||
<filename>.nspawn</filename> files consult
|
||||
<filename>.nspawn</filename> files, consult
|
||||
<citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
|
||||
|
||||
<para>If this option is set to <option>override</option> the
|
||||
file is searched, read and used the same way, however the order of
|
||||
<para>If this option is set to <option>override</option>, the
|
||||
file is searched, read and used the same way, however, the order of
|
||||
precedence is reversed: settings read from the
|
||||
<filename>.nspawn</filename> file will take precedence over
|
||||
the corresponding command line options, if both are
|
||||
specified.</para>
|
||||
|
||||
<para>If this option is set to <option>trusted</option> the
|
||||
<para>If this option is set to <option>trusted</option>, the
|
||||
file is searched, read and used the same way, but regardless
|
||||
if found in <filename>/etc/systemd/nspawn/</filename>,
|
||||
of being found in <filename>/etc/systemd/nspawn/</filename>,
|
||||
<filename>/run/systemd/nspawn/</filename> or next to the image
|
||||
file or container root directory, all settings will take
|
||||
effect, however command line arguments still take precedence
|
||||
effect, however, command line arguments still take precedence
|
||||
over corresponding settings.</para>
|
||||
|
||||
<para>If disabled no <filename>.nspawn</filename> file is read
|
||||
<para>If disabled, no <filename>.nspawn</filename> file is read
|
||||
and no settings except the ones on the command line are in
|
||||
effect.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -62,11 +62,11 @@
|
||||
<citerefentry><refentrytitle>file-hierarchy</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
queriable.</para>
|
||||
|
||||
<para>When invoked without arguments a list of known paths and
|
||||
<para>When invoked without arguments, a list of known paths and
|
||||
their current values is shown. When at least one argument is
|
||||
passed the path with this name is queried and its value shown.
|
||||
passed, the path with this name is queried and its value shown.
|
||||
The variables whose name begins with <literal>search-</literal>
|
||||
don't refer to individual paths, but instead to a list of
|
||||
do not refer to individual paths, but instead to a list of
|
||||
colon-separated search paths, in their order of precedence.</para>
|
||||
</refsect1>
|
||||
|
||||
|
||||
@ -55,7 +55,7 @@
|
||||
<title>Description</title>
|
||||
|
||||
<para><filename>systemd-random-seed.service</filename> is a
|
||||
service that restores the random seed of the system at early-boot
|
||||
service that restores the random seed of the system at early boot
|
||||
and saves it at shutdown. See
|
||||
<citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry>
|
||||
for details. Saving/restoring the random seed across boots
|
||||
|
||||
@ -55,7 +55,7 @@
|
||||
<title>Description</title>
|
||||
|
||||
<para><filename>systemd-remount-fs.service</filename> is an
|
||||
early-boot service that applies mount options listed in
|
||||
early boot service that applies mount options listed in
|
||||
<citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
to the root file system, the <filename>/usr</filename> file system,
|
||||
and the kernel API file systems. This is required so that the
|
||||
|
||||
@ -73,9 +73,9 @@
|
||||
<citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
and
|
||||
<citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for details. To improve compatibility
|
||||
for details. To improve compatibility,
|
||||
<filename>/etc/resolv.conf</filename> is read in order to discover
|
||||
configured system DNS servers, however only if it is not a symlink
|
||||
configured system DNS servers, but only if it is not a symlink
|
||||
to <filename>/run/systemd/resolve/resolv.conf</filename> (see above).</para>
|
||||
|
||||
<para><command>systemd-resolved</command> synthesizes DNS RRs for the following cases:</para>
|
||||
@ -124,10 +124,10 @@
|
||||
<para>If lookups are routed to multiple interfaces, the first
|
||||
successful response is returned (thus effectively merging the
|
||||
lookup zones on all matching interfaces). If the lookup failed on
|
||||
all interfaces the last failing response is returned.</para>
|
||||
all interfaces, the last failing response is returned.</para>
|
||||
|
||||
<para>Routing of lookups may be influenced by configuring
|
||||
per-interface domain names, see
|
||||
per-interface domain names. See
|
||||
<citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for details. Lookups for a hostname ending in one of the
|
||||
per-interface domains are exclusively routed to the matching
|
||||
|
||||
@ -80,7 +80,7 @@
|
||||
and thus shows up in the output of <command>systemctl
|
||||
list-units</command> like any other unit. It will run in a clean
|
||||
and detached execution environment, with the service manager as
|
||||
its parent process. In this mode <command>systemd-run</command>
|
||||
its parent process. In this mode, <command>systemd-run</command>
|
||||
will start the service asynchronously in the background and return
|
||||
after the command has begun execution.</para>
|
||||
|
||||
@ -239,7 +239,7 @@
|
||||
<term><option>--pty</option></term>
|
||||
<term><option>-t</option></term>
|
||||
|
||||
<listitem><para>When invoking a command as service connects
|
||||
<listitem><para>When invoking a command, the service connects
|
||||
its standard input and output to the invoking tty via a
|
||||
pseudo TTY device. This allows invoking binaries as services
|
||||
that expect interactive user input, such as interactive
|
||||
@ -355,7 +355,7 @@ Sep 08 07:37:21 bupkis env[19948]: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.
|
||||
|
||||
<para>The following command invokes the
|
||||
<citerefentry project='man-pages'><refentrytitle>updatedb</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
tool, but lowers the block IO weight for it to 10. See
|
||||
tool, but lowers the block I/O weight for it to 10. See
|
||||
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for more information on the <varname>BlockIOWeight=</varname>
|
||||
property.</para>
|
||||
|
||||
@ -54,7 +54,7 @@
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para><filename>systemd-sysctl.service</filename> is an early-boot
|
||||
<para><filename>systemd-sysctl.service</filename> is an early boot
|
||||
service that configures
|
||||
<citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
kernel parameters.</para>
|
||||
|
||||
@ -74,7 +74,7 @@
|
||||
specified in
|
||||
<citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
are searched for a matching file. If the string
|
||||
<filename>-</filename> is specified as filenames entries from the
|
||||
<filename>-</filename> is specified as filename, entries from the
|
||||
standard input of the process are read.</para>
|
||||
</refsect1>
|
||||
|
||||
|
||||
@ -63,7 +63,7 @@
|
||||
<para><ulink url="http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB headers</ulink>
|
||||
in SysV init scripts are interpreted, and the ordering specified
|
||||
in the header is turned into dependencies between the generated
|
||||
unit and other units. LSB facilities
|
||||
unit and other units. The LSB facilities
|
||||
<literal>$remote_fs</literal>, <literal>$network</literal>,
|
||||
<literal>$named</literal>, <literal>$portmap</literal>,
|
||||
<literal>$time</literal> are supported and will be turned into
|
||||
@ -73,7 +73,7 @@
|
||||
|
||||
<para>SysV runlevels have corresponding systemd targets
|
||||
(<filename>runlevel<replaceable>X</replaceable>.target</filename>).
|
||||
Wrapper unit that is generated will be wanted by those targets
|
||||
The wrapper unit that is generated will be wanted by those targets
|
||||
which correspond to runlevels for which the script is
|
||||
enabled.</para>
|
||||
|
||||
|
||||
@ -85,7 +85,7 @@
|
||||
<term><filename>/var/lib/systemd/clock</filename></term>
|
||||
|
||||
<listitem>
|
||||
<para>This file contains the timestamp of last successful
|
||||
<para>This file contains the timestamp of the last successful
|
||||
synchronization.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -103,7 +103,7 @@
|
||||
<term><option>--event-timeout=</option></term>
|
||||
<listitem>
|
||||
<para>Set the number of seconds to wait for events to finish. After
|
||||
this time the event will be terminated. The default is 180 seconds.</para>
|
||||
this time, the event will be terminated. The default is 180 seconds.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@ -58,7 +58,7 @@
|
||||
service that is invoked as part of the first boot after the vendor
|
||||
operating system resources in <filename>/usr</filename> have been
|
||||
updated. This is useful to implement offline updates of
|
||||
<filename>/usr</filename> which might requires updates to
|
||||
<filename>/usr</filename> which might require updates to
|
||||
<filename>/etc</filename> or <filename>/var</filename> on the
|
||||
following boot.</para>
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user