[systemd-devel] [HEADS-UP] Early-boot SysV service support is going away

[Koen Kooi]

Op 18 sep. 2012, om 00:59 heeft Lennart Poettering <lennart at poettering.net> het volgende geschreven:

> Heya,
> 
> In a month or two we'll make the SysV service logic in systemd
> generator-based. This helps us clean up our codebase a bit and makes
> SysV service support an optional plugin rather than something that is
> built into PID1.
> 
> Effectively, by doing this move very little will change in behaviour for
> SysV scripts, with one exception however: we will remove support for
> early-boot SysV scripts. Early-boot SysV scripts are those for the
> special "S", "boot", or "b" runlevel that exist on some distributions.
> These runlevels are highly distro specific, have never been really
> standardized and are really cumbersome to support right now with a lot
> of per-distribution hacks.
> 
> Please do not misunderstand this: it's one thing supporting normal SysV
> scripts, it's another one supporting them in the early boot part of the
> things. The former is going to stay for a long time, the latter however
> is going to be removed in a couple of month.
> 
> Anyway, this is basically just a heads-up about this, so that you folks
> who still need this can think about good solutions what to do
> instead. Here's what I can propose:
> 
> a) port the early-boot init scripts to native systemd units. You
> probably should do that anyway, and in most cases there should be very
> little left that systemd doesn't do on its own anyway in the early-boot
> process. We recommend to go this way, of course.
> 
> or 
> 
> b) Try to forward-port support for these magic runlvels to what's
> coming. Probably a lot of work, since due to the conversion to a
> generator this is a lot more work than it might appear right now. The
> code structure of the sysv logic will change quite substantially.
> 
> or 
> 
> c) write an explicit generator for these services, in the specific
> syntax of your distro. 
> 
> Anyway, please think about it, we'd just like to make you aware of this
> in time.
> 
> At least Debian, Suse, Ubuntu, Angstrom appear to be candidates where
> this lost functionality might be noticable.

I checked and the base system masks off all of those and uses systemd units for all the early stuff. So angstrom is safe :)

Does this change protect from dbus getting the short end of the stick when using a non-LSB sysv script? Systemd always seems to solve problems by not starting the dbus service in this case. I haven't filed a bug since it's only triggered by horribly broken sysv scripts and I managed to fix most of them (or used native units).

regards,

Koen