systemd LSB compat vs. $network and the rc2/rcS distinction

[Simon McVittie]

On 21/11/14 13:49, Patrick Matthäi wrote:
> please CC me in your e-mails, I'm not subscribed to this list.

(Same for me.)

> Am 20.11.2014 um 17:31 schrieb Simon McVittie:
>> It seems to me as though your dependency cycle is caused by
>> vmware-tools.service.
...
>> sysinit.target (must start before)
>> basic.target (which must start before)
>> vmware-tools.service (etc.)
>> network-online.target
>> rpcbind.service
>> sysinit.target (! back where we started)
>
> Thanks for your analyse of this problem. I think there should be a
> better solution, since this bug will be triggered on every VMware
> virtualized platform (since normaly you have to install their
> corresponding vmware-tools).

I've briefly investigated a similar dependency cycle on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763315 where it's
firewalld that wants to start before network.target.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761951 might be
something similar, I haven't analyzed that one to find the actual cycle
yet. There's also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622394 but I think
that one is entangling several distinct bugs (some of which might
already have been fixed).

Two potential solutions spring to mind:

* Make sure basic.target does not have to be After network.target, so
  services with DefaultDependencies or in rc2.d..rc5.d, but that do not
  depend on network.target or LSB $network, can safely start before
  networking.

  I think this would require finding all LSB rcS scripts that need
  networking, and giving them a native systemd unit (for simplicity, it
  could be one that just runs the init script for ExecWhatever).
  Notably, nfs-common and rpcbind would need this.

* Make sure that nothing Before network.target has DefaultDependencies.
  This would mean promoting NetworkManager, ConnMan, wicd, firewalld,
  etc. and their dependencies (notably, including dbus) to the
  equivalent of rcS under systemd,

  In the case of vmware-tools, we can't do this, because we don't
  control what VMWare ship; unless we can selectively override bits
  of it somehow?

* Apply some Breaks so known-bad combinations of packages (like
  firewalld and nfs-common) cannot be installed together. This seems
  like it should be a last resort if nothing else works.

I would be OK with making dbus not have DefaultDependencies if people
want me to; but bear in mind that whenever dbus can start, so can
non-systemd-activated system services, which are fairly likely to have
the implicit expectation that the equivalent of rcS already happened. So
I would prefer not to do that for jessie if I don't have to.

    S