Op 18 sep. 2012, om 00:59 heeft Lennart Poettering <lenn...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel