On Tue, May 21, 2019 at 10:50 AM Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote: > > >>> Andrei Borzenkov <arvidjaar@xxxxxxxxx> schrieb am 20.05.2019 um 19:07 in > Nachricht <4d103eef-d000-c9b2-9f7a-e0cda8ed625b@xxxxxxxxx>: > > 20.05.2019 16:36, Ulrich Windl пишет: > >> Hi! > >> > >> I have had the effect that a "systectl status" before and after a > >> "daemon-reload" is different, while the service in question wasn't > > restarted: > >> > > ...> > >> Is that intentional? > >> > > > > daemon-reload is known to lose state for years. Some problems get fixed, > > new problems appear. Problems range from cosmetic to losing state of > > units and jobs causing callers of systemd to "hang" waiting for job > > completion. Unfortunately daemon-reload is often the only answer to > > other reported problems (like in "systemd does not see fstab changes? > > Run daemon-reload, where is the problem"). > > So it's a bug? > Of course each specific bit of unit state which gets lost across daemon-reload is a bug. Although in this case it is rather cosmetic, as the main information is that unit is active which implies that all necessary commands have been executed. But more generally semantic of daemon-reload was never defined. What should happen if active unit definition has changed in incompatible way? Then run-time state no more matches unit definition and there is no "right" information that can be shown. _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel