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

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Simon McVittie <smcv@xxxxxxxxxxxxx> schrieb am 18.06.2020 um 16:42 in
Nachricht
<27143_1592491364_5EEB7D64_27143_46_1_20200618144233.GA644073@horizon>:
> On Thu, 18 Jun 2020 at 11:01:59 +0200, Jérémy ROSEN wrote:
>> 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.
> 
> Also, reloading is disruptive and can be "expensive" in terms of resource
> use. If you're making a lot of changes (like an upgrade transaction in
> a package manager like apt or RPM), you probably want to do the entire
> transaction, and then reload *once*.
> 
> dbus‑daemon *does* automatically reload when configuration or service files
> change. People now expect/rely on this, so it's undesirable to change,
> but with hindsight I wish it didn't. I think the fact that systemd
*doesn't*
> automatically reload is partly learning from dbus‑daemon's mistake.
> 
> On Thu, 18 Jun 2020 at 12:43:59 +0200, Ulrich Windl wrote:
>> Is there something like "systemd suggests daemon‑reload" (assuming systemd
>> detects the situation, but does not issue a reload itself)?
> 
> Yes there is:
> 
> $ systemctl status dbus.service
> (... some information here ...)
> $ sudo touch /lib/systemd/system/dbus.service
> $ systemctl status dbus.service
> Warning: The unit file, source configuration file or drop‑ins of
> dbus.service changed on disk. Run 'systemctl daemon‑reload' to reload
> units.
> (... same status information ...)
> 
> In this case I didn't really alter /lib/systemd/system/dbus.service,
> just changed its mtime, but you'd get the same thing from an edit that
> actually matters.

Yes, I've seen such message before, but I had been thinking of something like
a distinct exit status, or a specific query command.

> 
>     smcv



_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel