Issues enabling systemd template service using WantedBy construct (Styhead -> Walnascar)

Issues enabling systemd template service using WantedBy construct (Styhead -> Walnascar)

[Martin Siegumfeldt]

[-- Attachment #1: Type: text/plain, Size: 6570 bytes --]

Hi all,

We have encountered what appears to be a regression when moving from styhead to walnascar baseline, regarding a systemd service that is no longer enabled. It is a templated service that relates to another through the "WantedBy" relation - sample layer/recipes/service is available here: https://github.com/mnsgs/meta-systemd-test.

Recipe:

DESCRIPTION = "Wanted-by service"
LICENSE = "CLOSED"

inherit systemd

SRC_URI = "file://${BPN}@.service"

SYSTEMD_SERVICE:${BPN} = "\
${BPN}@a.service \
${BPN}@b.service \
"

do_install:append() {
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${UNPACKDIR}/${BPN}@.service ${D}${systemd_system_unitdir}
}

FILES:${PN} += "${systemd_system_unitdir}"

Systemd service file:

[Unit]
Description="Test WantedBy service %i"

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/echo "Hello from WantedBy service (instance %i)"
ExecStop=/bin/echo "Hello from Wantedby service (instance %i)"

[Install]
WantedBy=svc-wants@%i.service

On styhead baseline, this yields the  following behavior:

root@qemux86-64:~# cat /etc/buildinfo
-----------------------
Build Configuration:  |
-----------------------
DISTRO = poky
DISTRO_VERSION = 5.1.4
-----------------------
Layer Revisions:      |
-----------------------
meta              = styhead:70dc28ac287bf35541270cae1d99130a0f6b7b5f
meta-poky         = styhead:70dc28ac287bf35541270cae1d99130a0f6b7b5f
meta-yocto-bsp    = styhead:70dc28ac287bf35541270cae1d99130a0f6b7b5f
meta-systemd-test = main:b0b53555ffb7f43a7e9651bde2e9b710e5ded25f -- modified
root@qemux86-64:~#
root@qemux86-64:~# systemctl is-enabled svc-wanted-by@
indirect
root@qemux86-64:~#
root@qemux86-64:~# systemctl is-enabled svc-wanted-by@a
enabled
root@qemux86-64:~#
root@qemux86-64:~# journalctl -f&
root@qemux86-64:~# May 12 11:40:14 qemux86-64 systemd-timesyncd[200]: Network configuration changed, trying to establish connection.
May 12 11:40:14 qemux86-64 systemd-timesyncd[200]: Network configuration changed, trying to establish connection.
May 12 11:40:14 qemux86-64 systemd-logind[217]: New seat seat0.
May 12 11:40:14 qemux86-64 systemd-logind[217]: Watching system buttons on /dev/input/event0 (Power Button)
May 12 11:40:14 qemux86-64 systemd-logind[217]: Watching system buttons on /dev/input/event2 (QEMU QEMU USB Keyboard)
May 12 11:40:14 qemux86-64 systemd[1]: Started User Login Management.
May 12 11:40:14 qemux86-64 systemd[1]: Reached target Multi-User System.
May 12 11:40:14 qemux86-64 systemd[1]: Finished Virtual Console Setup.
May 12 11:40:14 qemux86-64 systemd[1]: Startup finished in 1.488s (kernel) + 3.613s (userspace) = 5.102s.
May 12 11:40:16 qemux86-64 systemd-timesyncd[200]: Network configuration changed, trying to establish connection.
May 12 11:40:46 qemux86-64 systemd-resolved[196]: Clock change detected. Flushing caches.
May 12 11:40:46 qemux86-64 systemd-journald[130]: Forwarding to syslog missed 126 messages.
May 12 11:40:46 qemux86-64 systemd-timesyncd[200]: Contacted time server 216.239.35.8:123 (time3.google.com).
May 12 11:40:46 qemux86-64 systemd-timesyncd[200]: Initial clock synchronization to Mon 2025-05-12 11:40:46.809039 UTC.
root@qemux86-64:~#
root@qemux86-64:~# systemctl start svc-wants@a
root@qemux86-64:~# May 12 11:40:54 qemux86-64 systemd[1]: Created slice Slice /system/svc-wanted-by.
May 12 11:40:54 qemux86-64 systemd[1]: Created slice Slice /system/svc-wants.
May 12 11:40:54 qemux86-64 systemd[1]: Starting "Test WantedBy service a"...
May 12 11:40:54 qemux86-64 systemd[1]: Starting "Test Wants service a"...
May 12 11:40:54 qemux86-64 echo[240]: Hello from WantedBy service (instance a)
May 12 11:40:54 qemux86-64 echo[241]: Hello from Wants service (instance a)
May 12 11:40:54 qemux86-64 systemd[1]: Finished "Test WantedBy service a".
May 12 11:40:55 qemux86-64 systemd[1]: Finished "Test Wants service a".

As expected, the "WantedBy" service is started along.

The equivalent on walnascar:

root@qemux86-64:~# cat /etc/buildinfo
-----------------------
Build Configuration:  |
-----------------------
DISTRO = poky
DISTRO_VERSION = 5.2
-----------------------
Layer Revisions:      |
-----------------------
meta              = walnascar:9b96fdbb0cab02f4a6180e812b02bc9d4c41b1a5
meta-poky         = walnascar:9b96fdbb0cab02f4a6180e812b02bc9d4c41b1a5
meta-yocto-bsp    = walnascar:9b96fdbb0cab02f4a6180e812b02bc9d4c41b1a5
meta-systemd-test = main:b0b53555ffb7f43a7e9651bde2e9b710e5ded25f -- modified
root@qemux86-64:~#
root@qemux86-64:~# systemctl is-enabled svc-wanted-by@
disabled
root@qemux86-64:~#
root@qemux86-64:~# systemctl is-enabled svc-wanted-by@a
disabled
root@qemux86-64:~#
root@qemux86-64:~# journalctl -f&
root@qemux86-64:~# May 12 11:42:14 qemux86-64 kernel[210]: [    3.173784] systemd-journald[133]: Received client request to flush runtime journal.
May 12 11:42:14 qemux86-64 systemd-logind[216]: New seat seat0.
May 12 11:42:14 qemux86-64 systemd[1]: Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch.
May 12 11:42:14 qemux86-64 systemd-logind[216]: Watching system buttons on /dev/input/event0 (Power Button)
May 12 11:42:14 qemux86-64 systemd-logind[216]: Watching system buttons on /dev/input/event2 (QEMU QEMU USB Keyboard)
May 12 11:42:14 qemux86-64 systemd[1]: Started User Login Management.
May 12 11:42:14 qemux86-64 systemd[1]: Reached target Multi-User System.
May 12 11:42:14 qemux86-64 systemd[1]: Starting Virtual Console Setup...
May 12 11:42:14 qemux86-64 systemd[1]: Finished Virtual Console Setup.
May 12 11:42:14 qemux86-64 systemd[1]: Startup finished in 1.495s (kernel) + 3.622s (userspace) = 5.118s.
root@qemux86-64:~#
root@qemux86-64:~# systemctl start svc-wants@a
root@qemux86-64:~# May 12 11:42:51 qemux86-64 systemd[1]: Created slice Slice /system/svc-wants.
May 12 11:42:51 qemux86-64 systemd-journald[133]: Forwarding to syslog missed 120 messages.
May 12 11:42:51 qemux86-64 systemd[1]: Starting "Test Wants service a"...
May 12 11:42:51 qemux86-64 echo[250]: Hello from Wants service (instance a)
May 12 11:42:51 qemux86-64 systemd[1]: Finished "Test Wants service a".

where the "WantedBy" service is not started (as it is not enabled)

As mentioned, it appears to be a regression during the styhead -> walnascar development. I notice that the systemctl-native is now built from the systemd sources - is this correct? Should I consequently report this through systemd?

Thanks,
Martin

[-- Attachment #2: Type: text/html, Size: 7995 bytes --]

Re: [OE-core] Issues enabling systemd template service using WantedBy construct (Styhead -> Walnascar)

[Alexander Kanavin]

On Mon, 12 May 2025 at 14:12, Martin Siegumfeldt via
lists.openembedded.org <mns=gomspace.com@lists.openembedded.org>
wrote:

> As mentioned, it appears to be a regression during the styhead -> walnascar development. I notice that the systemctl-native is now built from the systemd sources - is this correct? Should I consequently report this through systemd?

Yes, we've transitioned to using systemd's implementation rather than our own.

It's better if you reproduce and demonstrate this on a classic binary
distro, ideally the same on that upstream is using, and report using
that. Maybe in the process you'll instead find out something is
misconfigured in yocto or your build.

Alex

Re: [OE-core] Issues enabling systemd template service using WantedBy construct (Styhead -> Walnascar)

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

On Mon, May 12, 2025 at 02:19:14PM +0200, Alexander Kanavin wrote:
> On Mon, 12 May 2025 at 14:12, Martin Siegumfeldt via
> lists.openembedded.org <mns=gomspace.com@lists.openembedded.org>
> wrote:
> 
> > As mentioned, it appears to be a regression during the styhead -> walnascar development. I notice that the systemctl-native is now built from the systemd sources - is this correct? Should I consequently report this through systemd?
> 
> Yes, we've transitioned to using systemd's implementation rather than our own.
> 

I'm running into this same problem and I think there is a serious flaw
with walnascar / master.  We are using IPKs and what is happening is
that the `postinst` is not running correctly.  The `systemd_postinst` is
where all of the unit files are enabled (based on the SYSTEMD_SERVICE
variable).  If this doesn't run correctly, the image is missing all of
the default enabled services and templates.

The `systemd_postinst` has a guard "if systemctl >/dev/null 2>/dev/null"
and if this fails, none of the unit file enable code is ran.  The thing
is, `systemctl` will always fail because it by default is the same thing
as `systemctl list-units`, which needs to access the systemd bus
connection.

I modified systemd.bbclass as follows:

```
 systemd_postinst() {
+systemctl || echo "It failed for some reason"
 if systemctl >/dev/null 2>/dev/null; then
        OPTS=""
```

After this, my `log.do_rootfs` is full of:
```
Failed to connect to system scope bus via local transport: Operation not permitted (consider using --machine=<user>@.host --user to connect to bus of other user)
It failed for some reason
```

I think there needs to be some change in systemd_postinst to run
something other than the equivalent of `systemctl list-units` to
determine if the executable is valid.


-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]