[systemd-devel] Ordering between user at .service and systemd-logind.service

Lennart Poettering lennart at poettering.net
Mon Jul 1 10:39:17 UTC 2024


On Mo, 01.07.24 12:36, Lennart Poettering (lennart at poettering.net) wrote:

> On So, 30.06.24 22:48, Vladimir Kudrya (vladimir-csp at yandex.ru) wrote:
>
> > Hello everyone!
> >
> > I'm noticing an issue on my system (Debian sid) on shutdown. Wlroots
> > compositors try to communicate release of session to logind, but logind is
> > already gone, so conflicts arise due to activation attempts, journal is
> > spammed with stuff like this:
> >
> > Jun 29 10:38:13 hostname systemd[1]: Requested transaction contradicts existing jobs: Transaction for systemd-logind.service/start is destructive (dev-disk-by\x2dpath-pci\x2d0000:02:00.0\x2dnvme\x2d1\x2dpart-by\x2dlabel-swap_1.swap has 'stop' job queued, but 'start' is included in transaction).
> > Jun 29 10:38:13 hostname uwsm_sway.desktop[5886]: 00:27:37.977 [ERROR] [wlr] [libseat] [libseat/backend/logind.c:199] Could not close device: Could not activate remote peer 'org.freedesktop.login1': activation request failed: a concurrent deactivation request is already in progress
> >
> > Adding After=systemd-logind.service to user at .service seems to fix this issue
> > with no ill effects. But two questions arise: why there is no such ordering
> > by default, and is it conceptually correct?
>
> Hmm, so we typically don't sync on systemd-logind for user
> stuff/sessions if we can avoid that, since the root user is a user
> that shall be allowed logging in too, and typically much earlier than
> regular users, i.e long before logind is up.
>
> That said, given that user at .service is pretty much a logind concept, I
> guess we should have at least that dep in place.
>
> Can you please file an issue (or even better a PR), that adds the dep on
> logind to user at .service)? That'd be great!

(I guess this bug was introduced by
278e815bfa3e4c2e3914e00121c37fc844cb2025 btw, which had an indirect
dep in place, which was removed entirely. Replacing it with a
dependenc on systemd-logind.service should be safe and good afaics)

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list