[systemd-devel] [EXT] Re: Q: daemon-reload: when and how?

[Jérémy ROSEN]

Le jeu. 18 juin 2020 à 12:44, Ulrich Windl <
Ulrich.Windl at rz.uni-regensburg.de> a écrit :

> >>> Jérémy ROSEN <jeremy.rosen at smile.fr> schrieb am 18.06.2020 um 11:01 in
> Nachricht
>
> <19710_1592470931_5EEB2D93_19710_59_1_CAFvCimXJwvDg0+5W11H0pUh+EHDTGxgbAuAGpG2PL
> gjC0iX7A at mail.gmail.com>:
> > Le jeu. 18 juin 2020 à 08:53, Ulrich Windl <
> > Ulrich.Windl at rz.uni-regensburg.de> a écrit :
> >
> >> Hi!
> >>
> >> I have a question: systemd monitors almost everything it seems to me.
> So I
> >> wonder:
> >> Under what conditions is it necessary to issue a daemon-reload, and why
> >> can't systemd find out itself that a daemon-reload is required?
> >>
> >
> > There are some cases where systemd can detect the proper time for a
> > daemon-reload, and does it implicitely
> > systemd also check mtime of configuration files so it can see when a
> > daemon-reload should be done.
>
> Is there something like "systemd suggests daemon-reload" (assuming systemd
> detects the situation, but does not issue a reload itself)?
>
> Not that I know of...


> >
> > However it is not because a file has been modified that systemd should
> > decide to reload by itself.
> > multiple unit files need to work together to make a working environment,
> > and systemd can't know when all changes are consistent and
> > it is safe to reload. So systemd will want an explicit order from the
> user.
>
> I see (see above).
>
> >
> > So if I think a "manual" daemon-reload is required, is it safe to do it
> >> from within a unit?
> >>
> >
> > Usually, calling daemon-reload from a unit is a sign of bad design or
> > misunderstanding of some tool. What exactly is the problem you are
> > trying to solve ?
> >
> >
> >> I have a "generator-like" type of unit that changes the configuration of
> >> other units. However, as it seems, systemd ignores such changes until I
> use
> >> daemon-reload...
> >>
> >
> > Yes. you need an explicit daemon-reload here.
> > why can't it be a real generator ?
>
> AFAIK generators are quite low-level and have some restrictions. My unit is
> kind of high-level (e.g. it needs all filesystems mounted). Actually I
> started
> with a "normal" generator, but several restriction I can't remember right
> now
> made me change my mind to convert the generator to a "normal" (more or
> less)
> unit.
>
> generators are run very early during boot time so if you need external
filesystems
mounted, that can indeed be a problem.

> >
> > could you use systemd-run or the equivalent dbus API to do what you are
> > trying to do ?
>
> Good question! ;-) Browsing through the manpage I got the impression that
> it's
> systemd's version of "batch" IMHO. I'm unsure whether this has any
> advantage
> for my problem. For dbus I must admit that I have no experience of any kind
> with it...
>
> Well, it has the advantage of not needing a daemon-reload and of getting
rid of the
need to create a config file altogether... you talk directly to the running
instance of systemd

(i'm not sure what you mean by "batch" in this context. this is about
creating a unit, not some
kind of shell-script-like language)


> Regards,
> Ulrich
>
> [...]
>
>

-- 
[image: SMILE]  <http://www.smile.eu/>

20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique

[image: email] jeremy.rosen at smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>

[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200618/d4750856/attachment.htm>