[systemd-devel] ssh.service in rescue.target

Simon McVittie smcv at collabora.com
Mon Nov 9 16:12:45 UTC 2020


On Mon, 09 Nov 2020 at 09:16:05 -0500, Phillip Susi wrote:
> I guess I'll try masking it.

The Debian/Ubuntu package for systemd already masks various services
that are superseded by something in systemd, such as procps.service and
rcS.service. It used to also mask all the services from initscripts,
but that seems to have been dropped in version 243-5.

systemd-sysv-generator (which generates systemd service units corresponding
to sysv-rc services) has stopped generating units for sysv-rc services that
run in rcS, rc0 and rc6, but still generates units for rc1 (mapped to
rescue.target). killprocs runs in rc1.

Perhaps the systemd Debian/Ubuntu package still needs to mask rc1 services
like killprocs, or perhaps the initscripts package should take over
responsibility for masking rc1 services that it ships if they are not
applicable to systemd, or perhaps systemd-sysv-generator should ignore
services like killprocs that run in rc1?

> apt-cache depends util-linux says that it does not
> *depend* on it but *replaces* it.  Doesn't that mean that when
> util-linux is installed, initscripts should be removed?

Not necessarily, it isn't the same as RPM's Obsoletes field.
"util-linux Replaces initscripts" means that util-linux is allowed to
overwrite files that were previously shipped in initscripts. The rest
of initscripts is potentially still necessary (in fact it's unnecessary
when booting with systemd, but necessary when booting with sysv-rc).

Also, the Replaces is versioned: only old versions of initscripts are
replaced, and new versions are unaffected.

> initramfs-tools does not depend on initscripts, but *breaks* it, which
> should mean it is not possible for both packages to be installed at the
> same time.

initramfs-tools only Breaks initscripts (<< 2.88dsf-59.3~), which means
it is possible for both to be installed at the same time, as long as
initscripts is at a sufficiently new version.

    smcv


More information about the systemd-devel mailing list