[Pkg-systemd-maintainers] Bug#726027: Required-Start: $remote_fs for rcS type services (early boot) can lead to dependency loops

[Michael Biebl]

Package: systemd
Version: 204-5
Severity: normal

<mbiebl> so, I have an interesting issue here:
<mbiebl> NetworkManager.service has
<mbiebl> Wants=network.target
<mbiebl> Before=network.target
<mbiebl> and is started via multi-user.target
<mbiebl> remote-fs.target has a depenency on network.target
<mbiebl> and we do have rcS services which have Required-Start:    $remote_fs
<mbiebl> and as NetworkManager.service has a dependency on basic.target via DefaultDependencies=yes
<mbiebl> this leads to a loop
<mbiebl> any ideas how we can address this?
<mbiebl> (so far I have removed Wants/Before=network.target from NetworkManager.service, but that is not a solution)
<Mithrandir> any reason NM can't be pulled earlier?
<Mithrandir> it sounds like that might want to move to rcS?
<Mithrandir> (well sysinit)
<mbiebl> given that e.g. dbus (and other stuff like syslog) is started in rc2
<mbiebl> this wouldn't work (at least under sysvinit)
<Mithrandir> which bits in rcS need remote_fs?
<mbiebl> dbus.service is also hooked up via multi-user.target.wants
<Mithrandir> and do they actually need remote_fs or is that just the crazy "they need NFS" thing?
<mbiebl> we do setup the socket earlier
<mbiebl> but dbus system bus won't be functional until basic/sysinit target is done
<mbiebl> $ grep remote_fs *
<mbiebl> K19kbd:# Required-Start:    $remote_fs
<mbiebl> S19console-setup:# Required-Start:    $remote_fs
<mbiebl> S20alsa-utils:# Required-Start:    $local_fs $remote_fs
<mbiebl> S20alsa-utils:# Required-Stop:     $remote_fs
<mbiebl> S20bootmisc.sh:# Required-Start:    $remote_fs
<mbiebl> S20plymouth-log:# Required-Start:␉$local_fs $remote_fs
<mbiebl> S20plymouth-log:# Required-Stop:␉$local_fs $remote_fs
<mbiebl> S20x11-common:# Required-Start:    $remote_fs
<mbiebl> S20x11-common:# Required-Stop:     $remote_fs
<Mithrandir> I think we should get policy clarified that /, /usr and maybe /var are not remote fs-es.
<mbiebl> that is a huge mess indeed
<mbiebl> lumping $remote_fs and /usr together
<mbiebl> (never liked that)
<Mithrandir> It's arguable that /var can be a remote fs
<mbiebl> I was wondering if we should patch systemd to drop any refs to remote-fs.target
<mbiebl> for rcS type services
<mbiebl> ideally all those early boot services would ship native systemd support
<mbiebl> but with about 150 of them we need some solution
<mbiebl> during the transition period, I think
<mbiebl> imho, most of them don't belong in rcS
<mbiebl> but that's another matter
<Mithrandir> nod
<Mithrandir> I think https://wiki.debian.org/LSBInitScripts is wrong about $remote_fs
<Mithrandir> so I suggest we get the text changed to something like:
<Mithrandir> all filesystems are mounted.  Scripts depending on $remote_fs should not need to depend on $local_fs. During shutdown, scripts that need to run before sendsigs kills all processes should depend on $remote_fs.
<mbiebl> Unfortunately I think that ship has sailed
<mbiebl> I think 99% of the LSB headers have $remote_fs
<mbiebl> because their binaries are in /usr
<mbiebl> do you really expect to update all of them to use $local_fs instead?
<Mithrandir> I'd be fine with just whatever ships stuff in rcS
<Mithrandir> for the rest, it won't be a problem, will it?
<mbiebl> it shouldn't, no
<mbiebl> so adding a hack to systemd to s/remote-fs.target/local-fs.target/ for early boot services
<Mithrandir> given we require /usr to be available immediately post-initramfs, and sysvinit does approximately the same.
<mbiebl> do you think this is a crazy idea?
<Mithrandir> mbiebl: I'd be ok with it.
<Mithrandir> I'm just a bit careful about munging deps like that and causing deliberate differences wrt sysvinit



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  initscripts          2.88dsf-43
ii  libacl1              2.2.52-1
ii  libaudit1            1:2.3.2-2
ii  libblkid1            2.20.1-5.5
ii  libc6                2.17-93
ii  libcap2              1:2.22-1.2
ii  libcryptsetup4       2:1.6.1-1
ii  libdbus-1-3          1.6.16-1
ii  libgcrypt11          1.5.3-2
ii  libkmod2             15-0.1
ii  liblzma5             5.1.1alpha+20120614-2
ii  libpam0g             1.1.3-9
ii  libselinux1          2.1.13-3
ii  libsystemd-daemon0   204-5
ii  libsystemd-journal0  204-5
ii  libudev1             204-5
ii  libwrap0             7.6.q-24
ii  udev                 204-5
ii  util-linux           2.20.1-5.5

Versions of packages systemd recommends:
ii  libpam-systemd  204-5

Versions of packages systemd suggests:
ii  systemd-ui  2-2

-- no debconf information