On Thu, May 17, 2012 at 4:02 PM, Colin Guthrie <[email protected]> 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
