"I haven't noticed this behavior myself, and attempted a repro here on
v253 (Arch x86_64) just now."
-> 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.
"What do you mean by "disabled"?"
-> 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.
I am using systemd version 250.5 (plus the yocto patches):
# systemctl --version
systemd 250 (250.5+)
+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
With the default info log-level, I only see those logs after calling
"systemctl daemon-reload":
~ # Reloading.
systemd-logind.service: Deactivated successfully.
systemd-resolved.service: Deactivated successfully.
systemd-networkd.service: Deactivated successfully.
... (other services getting "deactivated")
~ #
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:
```
signal time=1702459928.818819 sender=:1.0 -> destination=(null destination)
serial=509 path=/org/freedesktop/systemd1;
interface=org.freedesktop.systemd1.Manager; member=Reloading
boolean true
...
signal time=1702459928.978736 sender=:1.0 -> destination=(null destination)
serial=1288 path=/org/freedesktop/systemd1;
interface=org.freedesktop.systemd1.Manager; member=UnitRemoved
string "local-fs.target"
object path "/org/freedesktop/systemd1/unit/local_2dfs_2etarget"
...
signal time=1702459929.769768 sender=:1.0 -> destination=(null destination)
serial=3395 path=/org/freedesktop/systemd1;
interface=org.freedesktop.systemd1.Manager; member=UnitNew
string "local-fs.target"
object path "/org/freedesktop/systemd1/unit/local_2dfs_2etarget"
...
signal time=1702459929.781640 sender=:1.0 -> destination=(null destination)
serial=3629 path=/org/freedesktop/systemd1;
interface=org.freedesktop.systemd1.Manager; member=JobNew
uint32 829
object path "/org/freedesktop/systemd1/job/829"
string "local-fs.target"
signal time=1702459929.781678 sender=:1.0 -> destination=(null destination)
serial=3630 path=/org/freedesktop/systemd1;
interface=org.freedesktop.systemd1.Manager; member=Reloading
boolean false
```
systemctl status local-fs.target also doesn't show why the unit is
"inactived (dead)". How would you debug this kind of issue?
Thanks,
Etienne
On Tue, Dec 12, 2023 at 10:07 PM Lennart Poettering
wrote:
> On Di, 12.12.23 19:06, Etienne Cordonnier (ecordonn...@snap.com) wrote:
>
> > Hello,
> > I am debugging some embedded system running systemd. The behavior I am
> > observing is that many systemd targets such as multi-user.target are
> > disabled after I run systemctl daemon-reload (as shown by systemctl
> > list-units --type target --all). This causes many systemd units to be
> > disabled, and forces me to reboot the system.
>
> What do you mean by "disabled"?
>
> in systemd targets can be active and inactive, and that's what
> "systemctl list-unit" shows. They can also be enabled/disabled, but
> that's what "systemctl list-unit-files" shows. But targets such as
> multi-user.target cannot be enabled nor disabled, they are considered
> "static", i.e. always enabled if you so will. Which "systemctl
> list-unit-file" should actually show.
>
> Hence, I don#t really grok what you are trying to say here...
>
> > Is there a way to debug this systemd target transition? I already
> > enabled systemctl
> > log-level debug, but I still don't understand why the systemd target is
> > changing when I call systemctl daemon-reload on this particular system.
>
> Please state OS, systemd version and provide relevant logs. Otherwise
> this is not actionable.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>
