<div dir="ltr">"I haven't noticed this behavior myself, and attempted a repro here on<br>v253 (Arch x86_64) just now."<br><br>-> Sorry for being unclear, I am talking about an embedded system with very significant customization (yocto based) and fully expect that the customization introduced the issue, so I didn't expect you to be able to reproduce. I am rather debugging this and asking for input on how to debug this kind of issue.<br><br>"What do you mean by "disabled"?"<br><br>-> I mean specifically that targets "basic.target", "local-fs.target" and "multi-user.target" are in the state "LOAD=loaded, ACTIVE=inactive, SUB=dead" after I call systemctl daemon-reload, whereas they are in the state "LOAD=loaded,ACTIVE=active,SUB-active" after I boot the system. I am trying to understand what causes this transition, but I don't see it in the logs at the moment.<br><br>I am using systemd version 250.5 (plus the yocto patches):<br><br># systemctl --version<br>systemd 250 (250.5+)<br>+PAM +AUDIT +SELINUX -APPARMOR +IMA -SMACK +SECCOMP -GCRYPT -GNUTLS -OPENSSL +ACL +BLKID -CURL +ELFUTILS -FIDO2 -IDN2 -IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -BZIP2 -LZ4 +XZ -ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=hybrid<br><br><br>With the default info log-level, I only see those logs after calling "systemctl daemon-reload":<br>~ # Reloading.<br>systemd-logind.service: Deactivated successfully.<br>systemd-resolved.service: Deactivated successfully.<br>systemd-networkd.service: Deactivated successfully.<br>...  (other services getting "deactivated")<br>~ # <br><br>I also tried reading the debug log-level logs, as well as the output of dbus-monitor --system but I still don't understand where the error is. Taking local-fs.target as an exemple, those are the logs from dbus-monitor --system after running systemctl daemon-reload, but those logs actually don't show an error:<br><br>```<br>signal time=1702459928.818819 sender=:1.0 -> destination=(null destination) serial=509 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=Reloading<br>   boolean true<br>...<br>signal time=1702459928.978736 sender=:1.0 -> destination=(null destination) serial=1288 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=UnitRemoved<br>   string "local-fs.target"<br>   object path "/org/freedesktop/systemd1/unit/local_2dfs_2etarget"<br>...<br>signal time=1702459929.769768 sender=:1.0 -> destination=(null destination) serial=3395 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=UnitNew<br>   string "local-fs.target"<br>   object path "/org/freedesktop/systemd1/unit/local_2dfs_2etarget"<br>...<br>signal time=1702459929.781640 sender=:1.0 -> destination=(null destination) serial=3629 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=JobNew<br>   uint32 829<br>   object path "/org/freedesktop/systemd1/job/829"<br>   string "local-fs.target"<br>signal time=1702459929.781678 sender=:1.0 -> destination=(null destination) serial=3630 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=Reloading<br>   boolean false<br>```<br> <br>systemctl status local-fs.target also doesn't show why the unit is "inactived (dead)".  How would you debug this kind of issue?<br><br>Thanks,<br>Etienne</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 12, 2023 at 10:07 PM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Di, 12.12.23 19:06, Etienne Cordonnier (<a href="mailto:ecordonnier@snap.com" target="_blank">ecordonnier@snap.com</a>) wrote:<br>
<br>
> Hello,<br>
> I am debugging some embedded system running systemd. The behavior I am<br>
> observing is that many systemd targets such as multi-user.target are<br>
> disabled after I run systemctl daemon-reload (as shown by systemctl<br>
> list-units --type target --all). This causes many systemd units to be<br>
> disabled, and forces me to reboot the system.<br>
<br>
What do you mean by "disabled"?<br>
<br>
in systemd targets can be active and inactive, and that's what<br>
"systemctl list-unit" shows. They can also be enabled/disabled, but<br>
that's what "systemctl list-unit-files" shows. But targets such as<br>
multi-user.target cannot be enabled nor disabled, they are considered<br>
"static", i.e. always enabled if you so will. Which "systemctl<br>
list-unit-file" should actually show.<br>
<br>
Hence, I don#t really grok what you are trying to say here...<br>
<br>
> Is there a way to debug this systemd target transition? I already<br>
> enabled systemctl<br>
> log-level debug, but I still don't understand why the systemd target is<br>
> changing when I call systemctl daemon-reload on this particular system.<br>
<br>
Please state OS, systemd version and provide relevant logs. Otherwise<br>
this is not actionable.<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div>