Your message dated Sun, 23 Aug 2015 17:18:00 +0200
with message-id <[email protected]>
and subject line Re: Bug#796690: screen: Has init script in runlevel S but no
matching service file
has caused the Debian Bug report #796690,
regarding screen: Has init script in runlevel S but no matching service file
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
796690: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796690
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: screen
Severity: important
User: [email protected]
Usertags: init-rcs-service
Hi,
Your package screen has an initscript that is enabled in runlevel S,
but it does not provide a corresponding systemd service unit.
Systemd generates units for all sysv init scripts that do not have a
corresponding systemd unit. By default, it sets
DefaultDependencies=yes, which means they get ordered after early
boot has finished.
The problem is that to preserve the runlevel S semantics, systemd in
debian is currently[1] ordering all S services Before=sysinit.target.
This target is particularly early in the boot sequence, which means
that it is most of the time too strict. In turn, this means it is
fairly easy to end up with dependency cycles. For an example, see bug
[763315]. Do note that the cycle still exists with sysvinit, it is
just that systemd complains more loudly.
Please add a systemd unit for the given service with the appropriate
dependencies, which most of the time will be less strict than
Before=sysinit.target. In other cases, the script is simply not
applicable in systemd, in which case the package should ship a
symlink to /dev/null as /lib/systemd/system/<initscript>.service.
We have prepared a transition wiki page[2] explaining the issue in
more detail, and outlining some general guidance. Please refer to it
as it will have useful information.
If you have any other doubts, feel free to ask in
[email protected]
--
[1]
http://sources.debian.net/src/systemd/222-2/debian/patches/Add-support-for-rcS.d-init-scripts-to-the-sysv-gener.patch/
[763315] https://bugs.debian.org/763315
[2] https://wiki.debian.org/Teams/pkg-systemd/rcSMigration
--- End Message ---
--- Begin Message ---
Hi,
from my point of view, this bug report is a false positive.
[email protected] wrote:
> Your package screen has an initscript that is enabled in runlevel S,
> but it does not provide a corresponding systemd service unit.
On purpose.
Please see
https://sources.debian.net/src/screen/4.3.1-1/debian/tmpfile/
https://sources.debian.net/src/screen/4.3.1-1/debian/postinst/#L24
https://sources.debian.net/src/screen/4.3.1-1/debian/postrm/#L11 for
the init script's systemd-ish replacement (which is not a service
file).
See https://bugs.debian.org/740301 and
https://bugs.launchpad.net/bugs/1462692 for the context of this
implementation -- which has been discussed on and implemented
according to suggestions from the pkg-systemd-maintainers list.
> Systemd generates units for all sysv init scripts that do not have a
> corresponding systemd unit.
Which is the reason for generating an according symlink to /dev/null
in postinst.
Regards, Axel
--
,''`. | Axel Beckert <[email protected]>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
--- End Message ---
