<para>On login, this module ensures the following:</para>
<orderedlist>
- <listitem><para>If it does not exist yet the
+ <listitem><para>If it does not exist yet, the
user runtime directory
<filename>/var/run/user/$USER</filename> is
created and its ownership changed to the user
that is logging in.</para></listitem>
<listitem><para>If
- <option>create-session=1</option> is set the
+ <option>create-session=1</option> is set, the
<varname>$XDG_SESSION_ID</varname> environment
variable is initialized. If auditing is
available and
<command>pam_loginuid.so</command> run before
- this module (which es recommended), the
+ this module (which is highly recommended), the
variable is initialized from the auditing
session id
(<filename>/proc/self/sessionid</filename>). Otherwise
used.</para></listitem>
<listitem><para>If
- <option>create-session=1</option> is set a new
+ <option>create-session=1</option> is set, a new
control group
<filename>/user/$USER/$XDG_SESSION_ID</filename>
is created and the login process moved into
it.</para></listitem>
<listitem><para>If
- <option>create-session=0</option> is set a new
+ <option>create-session=0</option> is set, a new
control group
<filename>/user/$USER/no-session</filename>
is created and the login process moved into
remaining processes in the
<filename>/user/$USER/$XDG_SESSION_ID</filename>
control group are killed and the control group
- removed.</para></listitem>
+ is removed.</para></listitem>
<listitem><para>If
<varname>$XDG_SESSION_ID</varname> is set and
<filename>/user/$USER/$XDG_SESSION_ID</filename>
control group are migrated to
<filename>/user/$USER/no-session</filename> and
- the original control group
+ the original control group is
removed.</para></listitem>
<listitem><para>If
<option>kill-user=1</option> is specified, and
- no other user session control group remains
+ no other user session control group remains,
except
- <filename>/user/$USER/no-session</filename>
+ <filename>/user/$USER/no-session</filename>,
all remaining processes in the
<filename>/user/$USER</filename> hierarchy
- are killed and the control group removed.</para></listitem>
+ are killed and the control group is removed.</para></listitem>
<listitem><para>If
<option>kill-user=0</option> is specified, and
</orderedlist>
<para>If the system was not booted up with systemd as
- init system this module does nothing and immediately
+ init system, this module does nothing and immediately
returns PAM_SUCCESS.</para>
</refsect1>
login process moved to the
<filename>/user/$USER/$XDG_SESSION_ID</filename>
control group. It is recommended that
- all services that are directly created
+ all services which are directly created
on the user's behalf set this
option. Only for services that shall
automatically be terminated when the
- user logs out completely otherwise,
+ user logs out completely, otherwise
<varname>create-session=0</varname>
should be set.</para></listitem>
</varlistentry>
completely. This is a weaker version
of <option>kill-session=1</option> and is
more friendly for users logged in more
- than once as their processes are
+ than once, as their processes are
terminated only on their complete
logout.</para></listitem>
</varlistentry>
<para>The two runlevel characters are seperated by a
single space character. If a runlevel cannot be
- determined N is printed instead. If neither can be
- determined the word "unknown" is printed.</para>
+ determined, N is printed instead. If neither can be
+ determined, the word "unknown" is printed.</para>
- <para>Unless overridden in the environment this will
+ <para>Unless overridden in the environment, this will
check the utmp database for recent runlevel
changes.</para>
</refsect1>
daemons become NOPs when -DDISABLE_SYSTEMD is set
during compilation. In addition, if
<filename>sd-daemon.c</filename> is compiled on
- non-Linux systems they become NOPs, too.</para>
+ non-Linux systems they become NOPs.</para>
</refsect1>
<refsect1>
<para>On failure, this call returns a negative
errno-style error code. If the system was booted up
- with systemd as init system this call returns a
+ with systemd as init system, this call returns a
positive return value, zero otherwise.</para>
</refsect1>
<para><function>sd_is_fifo()</function> may be called
to check whether the specified file descriptor refers
- to a FIFO or pipe. I
t the <parameter>path</parameter>
- parameter is not NULL it is checked whether the FIFO
+ to a FIFO or pipe. I
f the <parameter>path</parameter>
+ parameter is not NULL, it is checked whether the FIFO
is bound to the specified file system path.</para>
<para><function>sd_is_socket()</function> may be
<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- </para>
+ </para>
</refsect1>
</refentry>
for the service to work, hence it should not be
verified. On the other hand, whether a socket is a
datagram or stream socket matters a lot for the most
- common program logics and should hence be
- checked.</para>
+ common program logics and should be checked.</para>
<para>This function call will set the FD_CLOEXEC flag
for all passed file descriptors to avoid further
errno-style error code. If
<varname>$LISTEN_FDS</varname>/<varname>$LISTEN_PID</varname>
was not set or not correctly set for this daemon and
- hence no file descriptors received 0 is
+ hence no file descriptors received, 0 is
returned. Otherwise the number of file descriptors
- passed is returned, the application may find them
+ passed is returned. The application may find them
starting with file descriptor SD_LISTEN_FDS_START,
i.e. file descriptor 3.</para>
</refsect1>
definition file has Type=notify
set. The passed argument is a boolean
"1" or "0". Since there is little
- value in signalling non-readiness the
+ value in signalling non-readiness, the
only value daemons should send is
"READY=1".</para></listitem>
</varlistentry>
<listitem><para>Passes a single-line
status string back to the init system
that describes the daemon state. This
- is free-from and can be used for
+ is free-form and can be used for
various purposes: general state
feedback, fsck-like programs could
pass completion percentages and
<para>On failure, these calls return a negative
errno-style error code. If
<varname>$NOTIFY_SOCKET</varname> was not set and
- hence no status data could be sent 0 is returned. If
+ hence no status data could be sent, 0 is returned. If
the status was sent these functions return with a
- positive return value. In order to support both init
+ positive return value. In order to support both, init
systems that implement this scheme and those which
- don't it is generally recommended to ignore the return
+ don't, it is generally recommended to ignore the return
value of this call.</para>
</refsect1>
cannot be used to reload unit
configuration. Use the
<command>daemon-reload</command>
- command for that. All in all this
+ command for that. All in all, this
command is of little use except for
debugging.</para>
<para>This command should not be
<term><command>snapshot [NAME]</command></term>
<listitem><para>Create a snapshot. If
- a snapshot name is specified the new
+ a snapshot name is specified, the new
snapshot will be named after it. If
none is specified an automatic
snapshot name is generated. In either
- case the snapshot name used is printed
+ case, the snapshot name used is printed
to STDOUT.</para>
<para>A snapshot refers to a saved
configuration. This will reload all
unit files and recreate the entire
dependency tree. While the daemon is
- reloaded all sockets systemd listens
- on on behalf of user configuration will
+ reloaded, all sockets systemd listens
+ on on behalf of user configuration, will
stay accessible.</para> <para>This
command should not be confused with
the <command>load</command> or
daemon process. This is the
behaviour of traditional UNIX
daemons. If this setting is
- used it is recommended to also
+ used, it is recommended to also
use the
<varname>PIDFile=</varname>
option, so that systemd can
identify the main process of
- the daemon. systemd will start
- follow-up units as soon as the
- parent process exited.</para>
+ the daemon. systemd will proceed
+ starting follow-up units as soon
+ as the parent process exits.</para>
<para>If set to
<literal>simple</literal> (the
configured with
<varname>ExecStart=</varname>
is the main process of the
- daemon. In this mode
+ daemon. In this mode,
communication channels must be
available before the daemon is
- started up, as systemd will
- immediately start follow-up
- units.</para>
+ started up (sockets set up by systemd),
+ as systemd will immediately proceed
+ starting follow-up units.</para>
<para>Behaviour of
<literal>finish</literal> is
the daemon acquires a name on
the D-Bus bus, as configured
by
- <varname>BusName=</varname>. Follow-up
- units will be started after
- the name has been
+ <varname>BusName=</varname>. Systemd will
+ proceed starting follow-up
+ units after the D-Bus bus name has been
acquired.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>BusName=</varname></term>
<listitem>
- <para>Takes a D-Bus bus name
- that this service is reachable
+ <para>Takes a D-Bus bus name,
+ where this service is reachable
as. This option is mandatory
for services where
<varname>Type=</varname> is
target unit to all SysV
service units configured for
runlevel 1 to 5.</para>
- <para>Usually this should pull
- in all sockets, mount points,
+ <para>Usually this should pull-in
+ all sockets, mount points,
swap devices and other basic
initialization necessary for
the general purpose
- daemons. Most normal daemon
+ daemons. Most normal daemons
should have dependencies of
type After and Requires on
this unit.</para>
<para>The display manager
service. Usually this should
be aliased (symlinked) to
- <filename>gdm.service</filename>
+ <filename>xdm.service</filename>
or a similar display manager
service.</para>
<para>systemd automatically
adds dependencies of type
After for this target unit to
all SysV init script service
- units with an LSB header
+ units with a LSB header
referring to the
<literal>$x-display-manager</literal>
facility, for compatibility
<listitem>
<para>The mail transfer agent
(MTA) service. Usually this
- should pull in all units
+ should pull-in all units
necessary for
sending/receiving mails on the
local host.</para>
<varlistentry>
<term><varname>Alias=</varname></term>
- <listitem><para>Additional names this
+ <listitem><para>Additional names, this
unit shall be installed under. The
names listed here must have the same
suffix (i.e. type) as the unit file
name. This option may be specified
more than once, in which case all
listed names are used. At installation
- time
+ time,
<command>systemd-install</command>
will create symlinks from these names
to the unit file name. Note that this
<para>systemd is a system and session manager for
Linux operating systems. When run as first process on
- boot (as PID 1) it may act as init system that brings
- up and maintains userspace.</para>
+ boot (as PID 1), it acts as init system that brings
+ up and maintains userspace services.</para>
- <para>For compatibility with SysV if systemd is called
+ <para>For compatibility with SysV, if systemd is called
as <command>init</command> and a PID that is not
- 1 it will execute <command>telinit</command> and pass
+ 1, it will execute <command>telinit</command> and pass
all command line arguments unmodified. That means
<command>init</command> and <command>telinit</command>
are mostly equivalent when invoked from normal login sessions. See
D-Bus interfaces
repository. Optionally the interface
name for the introspection data may be
- specified. If omitted the
+ specified. If omitted, the
introspection data for all interfaces
is dumped.</para></listitem>
</varlistentry>
--variable=systemdsystemconfdir</command>
returns the path of the system
configuration directory. Packages
- should alter this directory only with
- the
+ should alter the content of these directories
+ only with the
<citerefentry><refentrytitle>systemd-install</refentrytitle><manvolnum>1</manvolnum></citerefentry>
tool.</para></listitem>
</varlistentry>
SysV init script directory varies
between distributions. If systemd
cannot find a native unit file for a
- requested service it will look for a
+ requested service, it will look for a
SysV init script of the same name
(with the
<filename>.service</filename> suffix
projects / systemd / commitdiff