[systemd-devel] Breaking ordering cycles... a suggestion.

Kay Sievers kay at vrfy.org
Thu May 17 07:18:13 PDT 2012


On Thu, May 17, 2012 at 4:02 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> I know this has been discussed a lot but it's still showing up for me on
> occasion, especially with 3rd party non-LSB init scripts.
>
> My suggestion would be to prioritise the jobs that we delete... can we
> tell that a job relates to a unit? And if so can we tell if a unit is
> sysv, lsb or native? If so I'd propose that when a job needs ot be
> deleted, we try to find a sysv job first, then an lsb then a native.
> That way we shouldn't end up with a sucky 3rd party sysv script killing
> prefdm startup as seems to be happening here:
> https://bugs.mageia.org/show_bug.cgi?id=5262#c36
>
> Would that be feasible?

Having some sort of context to be able to prioritize things makes
probably sense.

We've seen cases where some exotic storage daemon kicked out the D-Bus
unit from the transaction.

I guess preferring to kick units which are "manually" enabled in /etc,
over ones which are always statically enabled in /lib could have
slightly better results too.

The first step to improve things might be a simple way to validate the
initial transaction so that we can find out what's wrong before
rebooting. :)

> Or do you think it's not even worth it (medium
> term goal is probably to disable support for non-native units at compile
> time anyway I guess...)

I think we will keep that for a long time. We plan though, to rip out
all sysv code and provide the functionality with generators running at
bootup. This would read all the sysv init scripts and create .service
files in /run for them.

Kay


More information about the systemd-devel mailing list