SymbX/systemd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Drop remaining references about sysv script support

Browse Source 
Follow-up for 986fee6217.
This commit is contained in:
Yu Watanabe
2026-01-16 22:56:08 +09:00
parent 502d6f4bc9
commit 0a2cdd5891
10 changed files with 7 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/advanced-issue-labeler.yml
-3
View File
@@ -121,9 +121,6 @@ policy:
- name: sysusers
keys: ['systemd-sysusers']
- name: sysv
keys: ['systemd-sysv-generator']
- name: tests
keys: ['tests']
.github/labeler.yml
-6
View File
@@ -268,12 +268,6 @@ sysupdate:
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: [
README
-11
View File
@@ -434,17 +434,6 @@ GLIBC NSS:
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'
TODO
+1 -2
View File
@@ -2247,7 +2247,7 @@ Features:
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
@@ -2674,7 +2674,6 @@ Features:
* 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
docs/ENVIRONMENT.md
-2
View File
@@ -138,8 +138,6 @@ All tools:
* `$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.
docs/FAQ.md
-4
View File
@@ -81,10 +81,6 @@ Or you can even check /proc/$PID/cgroup directly. Also see [this blog story](htt
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:
docs/NETWORK_ONLINE.md
+2 -8
View File
@@ -70,16 +70,10 @@ For more details about those targets, see the
[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:
docs/index.md
+1 -1
View File
@@ -7,7 +7,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
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.
man/systemd.special.xml
+3 -20
View File
@@ -583,10 +583,6 @@
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
@@ -679,11 +675,6 @@
<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>
@@ -1185,9 +1176,7 @@ WantedBy=sleep.target</programlisting>
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>
@@ -1224,11 +1213,7 @@ WantedBy=sleep.target</programlisting>
<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>
@@ -1289,9 +1274,7 @@ WantedBy=sleep.target</programlisting>
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
meson.build
-1
View File
@@ -3188,7 +3188,6 @@ foreach tuple : [
['man pages', want_man],
['html pages', want_html],
['man page indices', want_man and have_lxml],
['SysV compat'],
['compat-mutable-uid-boundaries'],
['utmp'],
['ldconfig'],