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

Horst H. von Brand vonbrand at inf.utfsm.cl
Thu Jul 22 21:51:16 UTC 2010


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.

Nodz vigorously.

> 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:
> 
> if [ $1 -eq 1 ] ; then
>      systemctl enable foo.service
> else
>      systemctl daemon-reload

Huh? One you have to tell about the affected service, the other not?

Why not just "systemctl reload foo.service"?

Why not just "systemctl frob foo" (no ".service")?

>      # Optionally, make the update daemon restart or reload its configuration
>      systemctl reload-or-try-restart foo.service

Too verbose... "restart" would do for me (if changed, start the new one; if
old, just do a "killall -HUP service" or some such)

> fi
> 
> And for %preun it'll be:
> 
> if [ $1 -eq 0 ] ; then
>     systemctl disable --now foo.service
> fi

> Rationale:
> 
> "systemctl enable" installs the unit file in the system by creating the
> symlinks suggested in the unit file. It also implicitly reloads the
> configuration so that the init system knows about the changes.

OK.

> "systemctl daemon-reload" simply tells the init system to reload its
> configuration, no new symlinks are created.

Oh, now I get it. But this doesn't jibe. It is talking about _init_, not
the _services_ it manages. Perhaps this demands another command (name), or
a special argument? I.e., "systemctl reload init"?

> "systemctl reload-or-try-restart" tells the specified service to reload
> its configuration if it supports that. If it doesn't the daemon is
> restarted. This is identical to the LSB "force-reload" verb. However we
> chose to name this differently because we found "force-reload" not very
> descriptive. That said, the tool actually understands "force-reload"
> too, as equivalent (but it's not docuemnted). Something similar actually
> applies to condrestart. LSB calls Fedora's condrestart try-restart. We
> found the LSB name more descriptive and are advertising that, but we
> actually understand "condrestart" as an alias for it too. Anyway, all I
> wanna say here is that this nomenclature mostly stems from LSB though
> with some minimal changes, and we also understand the unmodified LSB and
> RH names for compat.

> "systemctl disable --now" removes the unit file symlinks from
> /etc/systemd/system, terminates the unit before this and reloads the
> init system configuration after this. The "--now" controls whether the
> unit is stopped or not.
> 
> I hope this simplification sounds good to many of you.

Much better. Tghanks!
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  +56 32 2797513


More information about the devel mailing list