Bug 7800

For future reference, oe-core accepts patches through the mailing list not bugzilla.

Adding the paths to the search path gets the files packaged correctly, but doesn't that then result in invalid postinst scripts being written?  ie if I have a recipe that installs a foo user unit, the init script attempts to enable the foo system unit.

Yes, you may be correct with regarding to the enabling part. I'm working on related stuff during next days (enabling systemd user session with dbus + pulseaudio + weston). 

I still have to check deeply but I guess a solution would be to check in systemd.bbclass if path contains systemd/user and then use systemctl --global enable instead of systemctl --system enable.

I will provide next solution on mailing list and share link to this bug report. Thank you for reviewing.

I sent some comments to the mailing list like a week ago with the work done so far but I got no response yet: 
https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg42187.html

I asked for information in systemd IRC channel on expected behavior for systemctl problem, but I got no answer.

I also added a bug report in systemd bugzilla in order to clarify the behaviour. It can be found in here:
https://bugs.freedesktop.org/show_bug.cgi?id=90897

So, for me this ticket is kind of blocked until we we get some answer from someone with more knowledge on systemd or systemctl specifically, or fins another better way to achieve something similar to what I'm trying to achieve.

It seems systemctl --global is finally working together with --root at least since version 229.

As v229 is currently being used (from what I could see in git recipes), this improvement could be pushed forward.

I'm not having a lot of time to invest on this lately and I don't usually work with any OE environment nowadays, therefore if somebody wants to pick up this task he is more than welcome. Otherwise I may work on it at some point but unclear when that's gonna be.

Could you please provide more details for your problem?

I can see that the systemd user deamon (/lib/systemd/systemd --user) is not started in our system. Is it the key problem here?

No, this ticket is not about "systemd --user" not being started, it is about systemd-user services not being installed automatically by systemd.bbclass and so not started correctly when "systemd --user" starts if they were not manually enabled in their own bb recipe at install time.

git://git.openembedded.org/openembedded-core-contrib ChenQi/systemd-user-units
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/systemd-user-units

Chen Qi (3): 
  systemd-systemctl: add option to manage user services
  systemd.bbclass: add support to manage user services
  pulseaudio: fix to manage user services corretly

As the codes might have some impact, move it to 2.3.

The current status of systemd has no such problem as the user instance of systemd daemon could be correctly started.

As far as I can tell, in current poky.git ./meta/classes/systemd.bbclass, .service files under ${systemd_user_unitdir} are not being checked and included into $FILES_FOO (foo as in foreach $SYSTEMD_PACKAGES) like the ones done in ${systemd_system_unitdir}.

So I reopen the issue because it's still not fixed. systemd.bbclass continues to ignore systemd user services files.

Chen Qi - Please review again, if needed set into NEEDINFO to get configuration that doesn't work.

Move from 3.3-M2 to 3.3 since medium priority bugs are not targeted to a milestone.

Himani, can you check if this feature is present and working on oe-core/master.
We think it was fixed in Jan 2025. It would be nice to add a test case.

I think this was addressed by the patches from Artur in around around this patch:
https://git.openembedded.org/openembedded-core/commit/?id=df1cdf1bf4cd7d9f17c6a02538057ccfc2efba64

Himani, Can you or a co-worker check on this. 
As Richard said, it seems like the problem has been resolved
so we'd like you to confirm first and then maybe write a test case.

Confirmed fixed on oe-core/master.

Artur Kowalski's patch series (merged Jan 2025, signed-off by Richard Purdie) fully addresses this. 

Key commits:

- df1cdf1bf4 systemd.bbclass: add ${sysconfdir}/systemd/user to search path
- 9a89d36932 systemd.bbclass: introduce systemd_service_searchpaths()
- 0218542d80 systemd.bbclass: properly handle user units in systemd_create_presets
- ce62b88d8f systemd.bbclass: support user units in postinst and prerm hooks

Code inspection on current master confirms:
- User unit search paths (${systemd_user_unitdir} and ${sysconfdir}/systemd/user) are included
- systemctl --global enable/disable/preset is used for user services
- Separate user-preset files are generated
- postinst and prerm scripts correctly differentiate system vs user units

Regarding a test case: there is currently no dedicated oe-selftest for user unit handling in systemd.bbclass. I can look into writing one if needed — it would involve a minimal recipe that installs a service to ${systemd_user_unitdir} and verifies the postinst uses --global and a user-preset file is generated. Let me know if you'd like me to proceed with that.

This bug can be closed as RESOLVED/FIXED.

Thanks Himani. 

Pau all good ? If so please close the bug.

---

Himani, 

I'd like to to create an YP enhancement to investigate
reviving the ptest coverage for systemd.

A quick search of the systemd git repo suggests that there are tests
for user units:
---
systemd.git on main
❯ rg "user unit" test/
test/units/TEST-55-OOMD.sh
162:    # Make sure we also work correctly on user units.

test/units/TEST-91-LIVEUPDATE.sh
23:# Ensure user units can also manage sessions

test/units/TEST-26-SYSTEMCTL.sh
611:# Test 1: Create a new global user unit with --force and --runtime

test/units/TEST-50-DISSECT.mountfsd.sh
127:# If the kernel support is present unprivileged user units should be able to use verity images too
---

We had ptest coverage for systemd back in 2018, 
until we updated to building systemd using meson:

https://git.openembedded.org/openembedded-core/commit/?id=906230a73b3ccfa4afd2a19a6b0aa18cd1d5fa08
...
    This new version has dropped ptest support, as there's no easy
    way to do this in the framework of meson.
---

Of course meson may have improved since then! 

I don't see a relevant systemd+ptest bug already:
https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=systemd&list_id=663779

so please create one and mention it here.

Then pass the bug in NEEDINFO state to Pau to close.

Created Bug 16386 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=16386 to track investigation of reviving ptest coverage for systemd, including user unit tests.

Setting to NEEDINFO for Pau to close.

Hi, as you may have noticed this bug report was opened quite a long time ago (almost 10 years!), and I haven't been doing related work since also quite a lot of time, so it's hard for me to validate or test current state right now.

Hence, letting you decide on whether the issue has been properly fixed and whether the bug report can finally be closed :-)

Thanks Pau. Closing this as RESOLVED/FIXED.

The fix has been confirmed on oe-core/master via Artur Kowalski's patch series (merged Jan 2025). The issue is fully addressed.