You are not logged in.
Following the slock section of arch linux wiki, I created and enabled such service for my user; it works fine, except that it fails if I suspend with no user logged in: in such case when I recover from suspend, the unit is listed by systemctl as failed.
Is such a use case not contemplated by what is described in the wiki? or am I missing something?
Offline
If you aren't logged in, which session do you expect to be locked by the locker?
Last edited by V1del (2018-02-08 12:28:40)
Offline
To elaborate a bit on the above, you say no user is logged in, but I find that unlikely. You refer to a user service and say you enabled it for your user. If you are not logged in at all, then the service should never even attempt to run. If it even attempts to run when you are not logged in, report it as a systemd bug.
I suspect what you mean though is that you are logged in, just not running X. If that's the case, what do you think the result of running an Xorg client program would be?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Well technically they aren't running an user service but a system service passing an user as an argument, which afaik is fine in this case, since you don't have access to the sleep target from a traditional user service anyway and it will be ran unconditionally no matter if the target user is logged in.
Offline
Oops, yes, that is what's in the wiki. A bit ambiguous though in saying it was enabled for a user.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
To elaborate a bit: I'm using dwm, and if I log out of dwm then I'm back to tty1, prompting for user/pwd. if I suspend from inside dwm, no problem, it locks etc; if I suspend from tty1 (i.e. logged out with the prompt for user/pwd) it still suspends, but when I log back in the service is reported as failed; if I suspend again from inside, it still works and locks it, and when I come back it is not anymore failed. Is this normal?
Offline
here's the corresponding entry in the journal
systemd[1]: Failed to start Lock X session using slock for user zzz.
-- Subject: Unit slock@zzz.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit slock@zzz.service has failed.
--
-- The result is RESULT.
Offline
Did you read *any* of the responses you received? Yes, it's normal.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
in /etc/systemd/system/slock@.service I have
[Unit]
Description=Lock X session using slock for user zzz
Before=sleep.target
[Service]
User=zzz
Environment=DISPLAY=:0
ExecStartPre=/usr/bin/xset dpms force suspend
ExecStart=/usr/bin/slock
[Install]
WantedBy=sleep.target
and i enabled it with sudo systemctl enable slock@zzz.service
Offline
Then I would say it's not optimal behavior of systemd
Offline
How on earth is this to blame on systemd?
You tell systemd to run a process. Systemd runs that process. That process fails. Blame systemd?
The process fails because you are trying to run an X11 program when X11 is not running. It's as simple as that. It would fail if it was run by systemd or by anything else.
Also, please use the EDIT button rather than multiposting.
Last edited by Trilby (2018-02-08 15:45:19)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
It's stupid to tie a service to my user and then run it even if my user is not logged in. V1del's comment explains how this works, but I think this is not a good solution for this case.
Offline
It's stupid to tie a service to my user and then run it even if my user is not logged in.
Then don't tell systemd to do that. It's just doing what you ask.
You could put an extra ExecStartPre command that checks whether you're logged in and running X. But the end result would be the same: if that check fails, it would not try to run slock, but there'd still be a log entry that the service failed (because the check failed). So the check is completely redundant. Slock failing does no harm.
Last edited by Trilby (2018-02-08 16:11:20)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Your service is not tied to your user an @ doesn't magically tie anything to your user, it creates a separate instance of the service with the argument you pass to it (and the User= directive only ensures that said program is run as your user, however one can run programs as a specific user without being logged in, which is what is happening there). I did some cursory reading and it might be possible to really tie the service to your user instance, however there's little to gain from really going deeper into this other than that you will not see a irrelevantly failing service.
Offline