- name: sysusers
keys: ['systemd-sysusers']
- - name: sysv
- keys: ['systemd-sysv-generator']
-
- name: tests
keys: ['tests']
sysusers:
- changed-files:
- any-glob-to-any-file: '**/*sysusers*'
-sysv-generator:
- - changed-files:
- - any-glob-to-any-file: '**/*sysv-generator*'
-sysvcompat:
- - changed-files:
- - any-glob-to-any-file: '**/*sysv*'
tests:
- changed-files:
- any-glob-to-any-file: [
gshadow: files systemd
hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
-SYSV INIT.D SCRIPTS:
- When calling "systemctl enable/disable/is-enabled" on a unit which is a
- SysV init.d script, it calls /usr/lib/systemd/systemd-sysv-install;
- this needs to translate the action into the distribution specific
- mechanism such as chkconfig or update-rc.d. Packagers need to provide
- this script if you need this functionality (you don't if you disabled
- SysV init support).
-
- Please see src/systemctl/systemd-sysv-install.SKELETON for how this
- needs to look like, and provide an implementation at the marked places.
-
WARNINGS and TAINT FLAGS:
systemd requires that the /run mount point exists. systemd also
requires that /var/run is a symlink to /run. Taint flag 'var-run-bad'
being properly synchronous we just keep open the fd and close it
when done. That means clients do not get a successful method reply,
but much rather a disconnect on success.
- - when breaking cycles drop sysv services first, then services from /run, then from /etc, then from /usr
+ - when breaking cycles drop services from /run first, then from /etc, then from /usr
- when a bus name of a service disappears from the bus make sure to queue further activation requests
- maybe introduce CoreScheduling=yes/no to optionally set a PR_SCHED_CORE cookie, so that all
processes in a service's cgroup share the same cookie and are guaranteed not to share SMT cores
* document:
- document that deps in [Unit] sections ignore Alias= fields in
[Install] units of other units, unless those units are disabled
- - man: clarify that time-sync.target is not only sysv compat but also useful otherwise. Same for similar targets
- document that service reload may be implemented as service reexec
- add a man page containing packaging guidelines and recommending usage of things like Documentation=, PrivateTmp=, PrivateNetwork= and ReadOnlyDirectories=/etc /usr.
- document systemd-journal-flush.service properly
* `$SYSTEMCTL_INSTALL_CLIENT_SIDE=1` — if set, enable or disable unit files on
the client side, instead of asking PID 1 to do this.
-* `$SYSTEMCTL_SKIP_SYSV=1` — if set, do not call SysV compatibility hooks.
-
* `$SYSTEMCTL_SKIP_AUTO_KEXEC=1` — if set, do not automatically kexec instead of
reboot when a new kernel has been loaded.
A: Unfortunately that would be a racy operation. For an explanation why and how we tried to improve the situation, see [the bugzilla report about this](https://bugzilla.redhat.com/show_bug.cgi?id=615527).
-**Q: I have a native systemd service file and a SysV init script installed which share the same basename, e.g. /usr/lib/systemd/system/foobar.service vs. /etc/init.d/foobar -- which one wins?**
-
-A: If both files are available the native unit file always takes precedence and the SysV init script is ignored, regardless whether either is enabled or disabled. Note that a SysV service that is enabled but overridden by a native service does not have the effect that the native service would be enabled, too. Enabling of native and SysV services is completely independent. Or in other words: you cannot enable a native service by enabling a SysV service by the same name, and if a SysV service is enabled but the respective native service is not, this will not have the effect that the SysV script is executed.
-
**Q: How can I use journalctl to display full (= not truncated) messages even if less is not used?**
A: Use:
[systemd.special(7)](https://www.freedesktop.org/software/systemd/man/systemd.special.html)
man page.
-## Compatibility with SysV init
-
-LSB defines a `$network` dependency for legacy init scripts. Whenever systemd
-encounters a `$network` dependency in LSB headers of init scripts it will
-translate this to `Wants=` and `After=` dependencies on
-`network-online.target`, staying relatively close to traditional LSB behaviour.
-
# Discussion
-The meaning of `$network` is defined [only very
+LSB defines a `$network` dependency for legacy init scripts.
+However, it is defined [only very
unprecisely](http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/facilname.html)
and people tend to have different ideas what it is supposed to mean. Here are a
couple of ideas people came up with so far:
systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system.
-systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. systemd supports SysV and LSB init scripts and works as a replacement for sysvinit.
+systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic.
Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.
functionality to other hosts (as opposed to <emphasis>consume</emphasis> functionality of other
hosts) generally do not need to pull this in.</para>
- <para>systemd automatically adds dependencies of type <varname>Wants=</varname> and
- <varname>After=</varname> for this target unit to all SysV init script service units
- with an LSB header referring to the <literal>$network</literal> facility.</para>
-
<para>Note that this unit is only useful during the original system start-up
logic. After the system has completed booting up, it will not track the online state of
the system anymore. Due to this it cannot be used as a network connection monitor
<listitem>
<para>Similar to <filename>local-fs.target</filename>, but
for remote mount points.</para>
-
- <para>systemd automatically adds dependencies of type
- <varname>After=</varname> for this target unit to all SysV
- init script service units with an LSB header referring to
- the <literal>$remote_fs</literal> facility.</para>
</listitem>
</varlistentry>
<varlistentry>
service lookups. Note that this is independent of UNIX user/group name lookups for which
<filename>nss-user-lookup.target</filename> should be used. All services for which the
availability of full host/network name resolution is essential should be ordered after
- this target, but not pull it in. systemd automatically adds dependencies of type
- <varname>After=</varname> for this target unit to all SysV init script service units
- with an LSB header referring to the <literal>$named</literal> facility.</para>
+ this target, but not pull it in.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>rpcbind.target</filename></term>
<listitem>
<para>The portmapper/rpcbind pulls in this target and orders
- itself before it, to indicate its availability. systemd
- automatically adds dependencies of type
- <varname>After=</varname> for this target unit to all SysV
- init script service units with an LSB header referring to
- the <literal>$portmap</literal> facility.</para>
+ itself before it, to indicate its availability.</para>
</listitem>
</varlistentry>
<varlistentry>
unit, but not pull it in.</para>
<para>The service manager automatically adds dependencies of type <varname>After=</varname> for
- this target unit to all SysV init script service units with an LSB header referring to the
- <literal>$time</literal> facility, as well to all timer units with at least one
- <varname>OnCalendar=</varname> directive.</para>
+ this target unit to all timer units with at least one <varname>OnCalendar=</varname> directive.</para>
<para>This target provides stricter clock accuracy guarantees than
<filename>time-set.target</filename> (see above), but likely requires
['man pages', want_man],
['html pages', want_html],
['man page indices', want_man and have_lxml],
- ['SysV compat'],
['compat-mutable-uid-boundaries'],
['utmp'],
['ldconfig'],
projects / thirdparty / systemd.git / commitdiff
