At Wednesday 16 July 2014 17:17:40 Lennart Poettering wrote: > I am a bit concerned about this, as we will never be able to find all > the units that PID 1 will find, for example because generated units are > not included in the client's search paths...
Right, but those cases have never been a problem for us, at least not yet... > What's the precise issue that this fixes? Aren't there better fixes for > that? For example by ensuring that chkconfig always also runs systemctl > enable/disable and vice versa, so that it never happens that a unit > might be enabled by one, but not by the other? We actually already do that, but I have yet to find a native service whose [Install] section exactly matches the Default-Start: field of the LSB header of the init script it is replacing... It gets even worse in Debian were we are forced to still support early boot init scripts (eg /etc/rcS.d/) that must run before basic.target, which are then replaced by native unit files on case-by-case basis, most of which are reworked to use DefaultDependencies=yes. Backwards compatibility is a bitch. While upstream systemd will not get the dependency cycle we do, in principle the problem is the same for any native service file shadowing a sysv init script.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
