sleep.target
is specific to system services. The reason is, sleep.target
is not a magic target that automatically gets activated when going to sleep. It's just a regular target that puts the system to sleep – so the 'user' instances of course won't have an equivalent. (And unfortunately the 'user' instances currently have no way to depend on systemwide services.)
(That, and there's the whole "hardcoding $DISPLAY" business. Every time you hardcode session parameters in an OS that's based on the heavily multi-user/multi-seat Unix, root kills a kitten.)
So there are two good ways to do this (I suggest the 2nd one):
Method 1
Create a system service (or a systemd-sleep(8) hook) that makes systemd-logind broadcast the "lock all sessions" signal when the system goes to sleep:
ExecStart=/usr/bin/loginctl lock-sessions
Then, within your X11 session (i.e. from ~/.xinitrc), run something that reacts to the signal:
systemd-lock-handler slock &
xss-lock --ignore-sleep slock &
(GNOME, Cinnamon, KDE, Enlightenment already support this natively.)
Method 2
Within your X11 session, run something that directly watches for the system going to sleep, e.g. by hooking into systemd-logind's "inhibitors".
The aforementioned xss-lock actually does exactly that, even without the explicit "lock all" signal, so it is enough to have it running:
xss-lock slock &
It will run slock
as soon as it sees systemd-logind preparing to suspend the computer.
You seem pretty close with your PAM conf line:
session [success=1 default=ignore] pam_succeed_if.so service in sudo quiet uid = 0
Looking at the manual page for pam_succeed_if
, I think you want to test that the requesting user (ruser
) is zabbix
.
So I suggest:
session [success=1 default=ignore] pam_succeed_if.so quiet uid = 0 ruser = zabbix
That will suppress the next test when user zabbix
becomes root
(but no other transitions). I've tested this with a pair of my own users.
Remove the uid = 0
test in the above if you want to keep quiet about zabbix
becoming any user, rather than just root.
I removed the service in sudo
test: it's redundant given that this line is in /etc/pam.d/sudo
.
Best Answer
This directory appears to be created by
pam_sytemd
. If you are comfortable losing the functionality described inman pam_systemd
, then you can edit/etc/pam.d/systemd-user
and comment out this line:Then reboot (or just try logging into a new session). I have not tested what side-effects this change might have, so beware!
The
pam_systemd.so
entry may be in another file, depending on your distribution and any local changes; others have reported that they had to edit/etc/pam.d/password-auth-ac
,/etc/pam.d/common-session
, or/etc/pam.d/runuser-l
.