/etc/init.d/screen-cleanup causes ordering cycle when package is removed

[Edward Z. Yang]

I recently rebooted my computer, and NetworkManager didn't come online. Snooping dmesg revealed the problem:

[ 16.371556] systemd[1]: Breaking ordering cycle by deleting job network.target/start
[ 16.371561] systemd[1]: Job network.target/start deleted to break ordering cycle starting with network-online.target/start
[ 16.371722] systemd[1]: Found ordering cycle on NetworkManager-wait-online.service/start
[ 16.371727] systemd[1]: Found dependency on NetworkManager.service/start
[ 16.371732] systemd[1]: Found dependency on basic.target/start
[ 16.371736] systemd[1]: Found dependency on sockets.target/start
[ 16.371739] systemd[1]: Found dependency on cups.socket/start
[ 16.371743] systemd[1]: Found dependency on sysinit.target/start
[ 16.371747] systemd[1]: Found dependency on screen-cleanup.service/start
[ 16.371751] systemd[1]: Found dependency on remote-fs.target/start
[ 16.371754] systemd[1]: Found dependency on openafs-client.service/start
[ 16.371758] systemd[1]: Found dependency on network-online.target/start
[ 16.371762] systemd[1]: Found dependency on NetworkManager-wait-online.service/start
[ 16.371766] systemd[1]: Breaking ordering cycle by deleting job NetworkManager.service/start
[ 16.371771] systemd[1]: Job NetworkManager.service/start deleted to break ordering cycle starting with NetworkManager-wait-online.service/start

Manually running `sudo systemctl start NetworkManager` brought it back online. But there shouldn't be an ordering cycle!

The problem seems to be that sockets wants cups, and then through a hilarious chain of events we hit openafs-client which obviously needs network. So for some reason, wants constraints are being honored too strictly.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: systemd 219-7ubuntu5
ProcVersionSignature: Ubuntu 3.19.0-18.18-generic 3.19.6
Uname: Linux 3.19.0-18-generic x86_64
NonfreeKernelModules: openafs
ApportVersion: 2.17.2-0ubuntu1.1
Architecture: amd64
Date: Sat Jun 6 15:49:54 2015
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-11-21 (562 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
MachineType: LENOVO 7762K3U
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-18-generic root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
SourcePackage: systemd
UpgradeStatus: Upgraded to vivid on 2015-05-29 (8 days ago)
dmi.bios.date: 02/21/2008
dmi.bios.vendor: LENOVO
dmi.bios.version: 7SET25WW (1.11 )
dmi.board.name: 7762K3U
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr7SET25WW(1.11):bd02/21/2008:svnLENOVO:pn7762K3U:pvrThinkPadX61Tablet:rvnLENOVO:rn7762K3U:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 7762K3U
dmi.product.version: ThinkPad X61 Tablet
dmi.sys.vendor: LENOVO

[Martin Pitt (pitti)]

[ 16.371747] systemd[1]: Found dependency on screen-cleanup.service/start

This seems to be the culprit. screen-cleanup is a service which needs to run before the very early sysinit.target, but requires remote-fs.target, which is unsatisfiable once you have remote file systems like openafs. Is that coming from a (third-party?) package or is that something that you added? Please give the output of

  systemctl cat screen-cleanup
  dpkg -S screen-cleanup.service init.d/screen-cleanup

Thanks!

[Edward Z. Yang (ezyang)]

openafs is:

ezyang@sabre:~$ aptitude show openafs-client
Package: openafs-client
State: installed
Automatically installed: yes
Version: 1.6.11.1-0ppa1~ubuntu15.04.1
Priority: optional
Section: net
Maintainer: Benjamin Kaduk <email address hidden>
[truncated]

which is coming from the official OpenAFS stable PPA: https://launchpad.net/~openafs/+archive/ubuntu/stable

Here's the other command output

ezyang@sabre:~$ systemctl cat screen-cleanup
# /run/systemd/generator.late/screen-cleanup.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/screen-cleanup
Description=LSB: screen sessions cleaning
DefaultDependencies=no
Before=sysinit.target
After=remote-fs.target

[Service]
Type=forking
Restart=no
TimeoutSec=0
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/init.d/screen-cleanup start
ExecStop=/etc/init.d/screen-cleanup stop

ezyang@sabre:~$ dpkg -S screen-cleanup.service init.d/screen-cleanup
dpkg-query: no path found matching pattern *screen-cleanup.service*
screen: /etc/init.d/screen-cleanup

[Martin Pitt (pitti)]

Uh, from screen .. What happened to /lib/systemd/system/screen-cleanup.service ? It should be a symlink to /dev/null.

What does

  ls -l /lib/systemd/system/screen-cleanup.service
  dpkg -s screen

show to you? Is screen perhaps removed, but not purged?

[Edward Z. Yang (ezyang)]

Yes, that diagnosis looks correct.

ezyang@sabre:~$ ls -l /lib/systemd/system/screen-cleanup.service
ls: cannot access /lib/systemd/system/screen-cleanup.service: No such file or directory
ezyang@sabre:~$ dpkg -s screen
Package: screen
Status: deinstall ok config-files
Priority: optional
Section: misc
Installed-Size: 983
Maintainer: Ubuntu Developers <email address hidden>
Architecture: amd64
Version: 4.2.1-2
Config-Version: 4.2.1-2
Depends: libc6 (>= 2.15), libpam0g (>= 0.99.7.1), libtinfo5
Suggests: iselect (>= 1.4.0-1) | screenie | byobu
Conffiles:
 /etc/init.d/screen-cleanup c1dc791ae42e2ce284cd20aff93e8987
 /etc/screenrc 12c245238eb8b653625bba27dc81df6a
 /etc/init/screen-cleanup.conf 441f4a1c5b41d7f23427be5aa6ccbbcc obsolete
Description: terminal multiplexer with VT100/ANSI terminal emulation
 GNU Screen is a terminal multiplexer that runs several separate "screens" on
 a single physical character-based terminal. Each virtual terminal emulates a
 DEC VT100 plus several ANSI X3.64 and ISO 2022 functions. Screen sessions
 can be detached and resumed later on a different terminal.
 .
 Screen also supports a whole slew of other features, including configurable
 input and output translation, serial port support, configurable logging,
 and multi-user support.
Original-Maintainer: Axel Beckert <email address hidden>
Homepage: http://savannah.gnu.org/projects/screen

[Martin Pitt (pitti)]

Thanks for confirming! As a local fix, please purge the screen package.

[Axel Beckert (xtaran)]

Dear Martin,

there is no /etc/init.d/screen-cleanup.service in the screen package. I assume you meant /etc/init.d/screen-cleanup.

[Axel Beckert (xtaran)]

Now for the right way to fix that:

I don't see any. /etc/init.d/screen-cleanup is a conffile and hence only removed upon purge (and surely won't be removed from the package).

On the other hand /lib/systemd/system/screen-cleanup.service is no conffile and hence will already be removed upon package removal.

Making /lib/systemd/system/screen-cleanup.service a conffile likely fixes the issue, but feels unclean as it's not in /etc/. So I suspect we should move it to /etc/systemd/system/screen-cleanup.service instead.

[Martin Pitt (pitti)]

Axel: A local fix would be to not ship the /lib/systemd/system/screen-cleanup.service link in the deb, but create it in postinst and remove it in the postrm on purge.

But perhaps this should be discussed on http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers first? This problem probably affects a handful of other packages. Maybe there is a really cheap way to determine that an init.d script is "orphaned" in that way so that the sysv-generator can ignore it. I can't think of any with the current information that we have on the system; this would at least need some additional help from dh_installinit/the maintainer scripts. But maybe someone has a clever idea.

[Launchpad Janitor (janitor)]

This bug was fixed in the package screen - 4.3.0-2

---------------
screen (4.3.0-2) unstable; urgency=low

  * Upload to unstable again.
  * Re-add debian/dirs with /etc/tmpfiles.d/ and add a comment why screen
    ships an empty directory.
    + Fixes regression introduced in 4.2.1-4: If systemd is not installed
      and screen is either setuid or neither setuid nor setgid,
      /var/lib/dpkg/info/screen.postinst bailed out with "16:
      /var/lib/dpkg/info/screen.postinst: cannot create
      /etc/tmpfiles.d/screen-cleanup.conf: Directory nonexistent".
    + See comment in debian/dirs for more detailed reasoning.
  * No more ship /lib/systemd/system/screen-cleanup.service in the package
    but link it to /dev/null in postinst and remove the link again in
    postrm. (LP: #1462692)
  * Add fixed bugs reported in Ubuntu to previous changelog entry.
  * Apply wrap-and-sort.

 -- Axel Beckert <email address hidden> Wed, 17 Jun 2015 21:57:18 +0200

[Martin Pitt (pitti)]

Cool, thanks Axel!