[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