iteration a single event source is dispatched. Each time an event

source is dispatched the kernel is polled for new events, before

the next event source is dispatched. The event loop is designed to

not designed to provide optimal throughput, as this contradicts

these goals due the limitations of the underlying <citerefentry

project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>

reliable. However, it is guaranteed that if events are seen on

multiple same-priority event sources at the same time, each one is

not dispatched again until all others have been dispatched

particular event sources do not starve or dominate the event

loop.</para>

<para><literal>ignore-requirements</literal> is similar to

<literal>ignore-dependencies</literal>, but only causes the

requirement dependencies to be ignored, the ordering

</listitem>

</varlistentry>

desired, combine this command with the <option>--now</option> switch, or invoke <command>start</command>

with appropriate arguments later. Note that in case of unit instance enablement (i.e. enablement of units of

the form <filename>foo@bar.service</filename>), symlinks named the same as instances are created in the

from.</para>

<para>This command expects either valid unit names (in which case various unit file directories are

<citerefentry><refentrytitle>systemd-sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>.

</para>

<filename>/etc/systemd/coredump.conf</filename> and corresponding snippets

<filename>/etc/systemd/coredump.conf.d/*.conf</filename>, see

<citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. A new

<refsect1>

<title>The udev Database</title>

properties of block devices:</para>

<variablelist class='udev-directives'>

purposes (usually in the range beyond the host's UID/GID 65536). The parameter may be specified as follows:</para>

<orderedlist>

parameter specifies the first host UID/GID to assign to the container, the second parameter specifies the

number of host UIDs/GIDs to assign to the container. If the second parameter is omitted, 65536 UIDs/GIDs are

assigned.</para></listitem>

range is automatically chosen. As first step, the file owner of the root directory of the container's

directory tree is read, and it is checked that it is currently not used by the system otherwise (in

particular, that no other container is using it). If this check is successful, the UID/GID range determined

the UID/GID range indicated in the root directory's file owner is already used elsewhere) a new – currently

unused – UID/GID range of 65536 UIDs/GIDs is randomly chosen between the host UID/GIDs of 524288 and

1878982656, always starting at a multiple of 65536. This setting implies

<option>--private-users-chown</option> (see below), which has the effect that the files and directories in

the container's directory tree will be owned by the appropriate users of the range picked. Using this option

container image might result in picking a new UID/GID range for it, and thus in the (possibly expensive) file

ownership adjustment operation. However, subsequent invocations of the container will be cheap (unless of

course the picked UID/GID range is assigned to a different use by then).</para></listitem>

<para>It is recommended to assign at least 65536 UIDs/GIDs to each container, so that the usable UID/GID range in the

container covers 16 bit. For best security, do not assign overlapping UID/GID ranges to multiple containers. It is

hence a good idea to use the upper 16 bit of the host 32-bit UIDs/GIDs as container identifier, while the lower 16

<option>--private-users=pick</option> option.</para>

<para>When user namespaces are used, the GID range assigned to each container is always chosen identical to the

and the subdirectory is symlinked into the host at the same

location. <literal>try-host</literal> and

<literal>try-guest</literal> do the same but do not fail if

<literal>auto</literal> (the default), and the right

subdirectory of <filename>/var/log/journal</filename> exists,

it will be bind mounted into the container. If the

when the user first logs in, and stays around as long as at least one

login session is open. After the user logs out of the last session,

<filename>user@.service</filename> and all services underneath it

not enabled for that user. Enabling lingering means that

<filename>user@.service</filename> is started automatically during

boot, even if the user is not logged in, and that the service is

<term><varname>CtrlAltDelBurstAction=</varname></term>

<listitem><para>Defines what action will be performed

Can be set to <literal>reboot-force</literal>, <literal>poweroff-force</literal>

or disabled with <literal>ignore</literal>. Defaults to

<literal>reboot-force</literal>.

the unit's own user and group to themselves and everything else to the <literal>nobody</literal> user and

group. This is useful to securely detach the user and group databases used by the unit from the rest of the

system, and thus to create an effective sandbox environment. All files, directories, processes, IPC objects and

from within the unit but appear owned by the <literal>nobody</literal> user and group. If this mode is enabled,

all unit processes are run without privileges in the host user namespace (regardless if the unit's own

user/group is <literal>root</literal> or not). Specifically this means that the process will have zero process

<varlistentry>

<term><varname>$MAINPID</varname></term>

known. This is only set for control processes as invoked by

<varname>ExecReload=</varname> and similar. </para></listitem>

</varlistentry>