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

[Colin Guthrie]

'Twas brillig, and Kay Sievers at 17/05/12 15:18 did gyre and gimble:
> 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. :)

Yeah I can certainly see that helping.

>> 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.

Ahh yes, I can see that being a cleaner system right enough. It would
still be nice to know that a given unit is actually sysv, lsb or native
tho' (and actually generating files in /run would kind of blur the "is
native" question a bit) for the purposes of this prioritisation, but I
guess just knowing if the unit was from lib, run or etc might be enough
in this case.



As for the ordering problem, another suggestion would be to use the now
available "Type=idle" unit to somehow retry any jobs that were
previously deleted to break a cycle when things have reached an idle
state. I'm not fully convinced this is a great idea, as it would
somewhat paper over the cracks if it worked too well :p


Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/