[systemd-devel] systemctl preset and chkconfig

[Lennart Poettering]

On Tue, 26.08.14 21:58, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> 
> В Tue, 26 Aug 2014 14:38:52 +0200
> Lennart Poettering <lennart at poettering.net> пишет:
> 
> > On Tue, 26.08.14 16:37, Andrei Borzenkov (arvidjaar at gmail.com) wrote:
> > 
> > > 
> > > On Tue, Aug 26, 2014 at 4:34 PM, Lennart Poettering
> > > <lennart at poettering.net> wrote:
> > > > On Tue, 26.08.14 16:29, Andrei Borzenkov (arvidjaar at 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