On Tue, 26.08.14 21:58, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > В Tue, 26 Aug 2014 14:38:52 +0200 > Lennart Poettering <lenn...@poettering.net> пишет: > > > On Tue, 26.08.14 16:37, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > > > > > > > On Tue, Aug 26, 2014 at 4:34 PM, Lennart Poettering > > > <lenn...@poettering.net> wrote: > > > > On Tue, 26.08.14 16:29, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > > > > > > >> >> I have to say tho', I'm surprised this is something implemented in > > > >> >> PID1. > > > >> >> I hadn't looked at the code, but I thought (well assumed) "systemctl > > > >> >> preset" was actually implemented on the client side. I guess it's > > > >> >> true > > > >> >> what they say about "assume"... :p > > > >> > > > > >> > Well, it's actually implemented on both sides (we link the same code > > > >> > into client and server), so that --root= can work, and so that it > > > >> > can be > > > >> > invoked if systemd is not running as PID 1. > > > >> > > > >> What is then rationale for having it in PID 1 at all? > > > > > > > > So that we can provide it as a bus API. > > > > > > And it *must* be in PID 1? Can it be systemd-install.service (pick the > > > name)? > > > > Well, you can also just leave it in PID 1. What's the point? > > > > Normal service has more relaxed requirements. In particular, nothing > really prevents it from supporting chkconfig :)
Well, I don't think this would really change much. I don#t want to invoooke chkconfig on the server side, since it's not a tool for that, for example expects to be invoked with stdout/stderr connected to the user console, and I am not convinced we really should completely change the modus how we invoke it... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel