[HEADS-UP] systemd for F14 - the next steps

Lennart Poettering mzerqung at 0pointer.de
Fri Jul 23 00:43:45 UTC 2010


On Thu, 22.07.10 20:40, Lennart Poettering (mzerqung at 0pointer.de) wrote:

> 
> On Thu, 22.07.10 08:05, Simo Sorce (ssorce at redhat.com) wrote:
> 
> > > to make real; give reality to (a hope, fear, plan, etc.).
> > >  
> > > but its seems quite an abstract term to associate reality with an
> > > abstract computer object.
> > 
> > Dave, I am not a native speaker, but I have the exact (or may be even
> > worse) problem. For as much as I try the syntax there is so obscure I
> > cannot "realize" what it means *at all*, just by looking at it.
> > 
> > 
> > Lennart, "realize" really is a bad bad bad choice, please consider
> > changing it while there is still time.
> 
> Kay and I have discussed this now. We agreed to fold systemd-install
> into systemctl entirely, and replace --realize by --now. Also, we'll
> drop some of the options --realize had, and always imply that the init
> system configuration shall be reloaded after all changes took
> place. This basically means that this
> is what will be done in %post in the general case:

Kay and I discussed that even further now and decided to scrap --now
entirely now. There's little reason left to keep this as flag around. I
think it is more descriptive to do this on %preun:

    systemctl stop postfix.service
    systemctl disable postfix.service

then it would be to do this:

    systemctl disable --now postfix.service.

Especially for "enable" this is even more the case, since depending on the
case you might or might not want to restart, or reload the service on
package upgrade. For example, restarting D-Bus or the gettys on package
uprgade would be a really bad idea, but restarting ntpd might be a good
idea. Given that packagers would have to specifiy anyway whether they
want to reload, or restart or nothing at all a service on upgrade we
think it would make more sense if they simply delcare their choice
explicitly and do either one fo this in %post:

    systemctl enable foobar.service
    systemctl try-restart foobar.service     ### restart if running

or:

    systemctl enable foobar.service
    systemctl reload foobar.service          ### reload if running

or just:

    systemctl enable foobar.service

or, for debian folks which want to start services after package installation:

    systemctl enable foobar.service
    systemctl restart foobar.service         ### restart if runnning, start if not running

I think this scheme is really simply now, as the operations issued are
first class commands, and no switches necessary. Also, the verbs here
are 1:1 from the LSB specs, and hence should offer no surprises to
anybody.

Everybody happy?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list