laptop suspend issues, and login/display_managers

hhh · 2017-10-05 00:08:32

MOD NOTE
This thread has been made public because there was nothing confidential in it, and forum members might be interested, or have contributions to make. Thanks!
johnraff
--------------

@John, is accountsservice part of the helium package list? I just installed it and it's solved the problems I've been having with laptop-lid close suspend. If I opened the lid again and then shut it without logging in, I was getting error notifications when I did finally login. Np now, and the login screen appears upon resume, before it was blank until I hit a key.

Last edited by johnraff (2017-10-17 02:28:19)

hhh · 2017-10-05 01:40:02

hhh wrote:

@John, is accountsservice part of the helium package list? I just installed it and it's solved the problems I've been having with laptop-lid close suspend. If I opened the lid again and then shut it without logging in, I was getting error notifications when I did finally login. Np now, and the login screen appears upon resume, before it was blank until I hit a key.

More testing, with this package we'll need to include the line...

KillUserProcesses=yes

... in /etc/systemd/logind.conf to prevent gnome-keyring-daemon from respawning at every login. On the plus side, with this 'fix' and including thunar --daemon, the desktop uses less RAM with more functionality at login and at idle.

Last edited by hhh (2017-10-05 01:44:07)

johnraff · 2017-10-06 08:17:30

hhh wrote:

@John, is accountsservice part of the helium package list?

No. The description doesn't immediately suggest why it should fix laptop login problems, but if it helps, and doesn't start any more daemons, we could add it. Others, OK with this?

Last edited by johnraff (2017-10-17 02:20:03)

Head_on_a_Stick · 2017-10-06 19:42:13

hhh wrote:

@John, is accountsservice part of the helium package list? I just installed it and it's solved the problems I've been having with laptop-lid close suspend. If I opened the lid again and then shut it without logging in, I was getting error notifications when I did finally login. Np now, and the login screen appears upon resume, before it was blank until I hit a key.

Suspend on lid close has always worked for me in the six or seven Helium-dev systems I have installed on my Haswell laptop (I will be trying the AMD laptop this weekend) so perhaps this is particular to your hardware.

Last edited by johnraff (2017-10-17 02:20:34)

johnraff · 2017-10-07 07:24:37

Head_on_a_Stick wrote:

hhh wrote:
@John, is accountsservice part of the helium package list? I just installed it and it's solved the problems I've been having with laptop-lid close suspend. If I opened the lid again and then shut it without logging in, I was getting error notifications when I did finally login. Np now, and the login screen appears upon resume, before it was blank until I hit a key.
Suspend on lid close has always worked for me in the six or seven Helium-dev systems I have installed on my Haswell laptop (I will be trying the AMD laptop this weekend) so perhaps this is particular to your hardware.

+1 (but I'll test on my laptop too)

Last edited by johnraff (2017-10-17 02:21:25)

Head_on_a_Stick · 2017-10-07 13:05:37

hhh wrote:

the problems I've been having with laptop-lid close suspend. If I opened the lid again and then shut it without logging in, I was getting error notifications when I did finally login.

My aplogies Has, I've just encountered this in my test system:

I'll try the accountsservice package now.

EDIT: the accountsservice package does not stop the error which I think appears because LightDM lacks the permissions to suspend the system before the user logs in.

Journal contents:

Oct 07 13:12:13 testbed lightdm[591]: Error using VT_WAITACTIVE 7 on /dev/tty0: Interrupted system call
Oct 07 13:12:13 testbed lightdm[1789]: pam_unix(lightdm-greeter:session): session closed for user lightdm
Oct 07 13:12:13 testbed org.a11y.atspi.Registry[1805]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
Oct 07 13:12:13 testbed org.a11y.atspi.Registry[1805]:       after 21 requests (21 known processed) with 0 events remaining.
Oct 07 13:12:14 testbed dhclient[2116]: XMT: Info-Request on wlp2s0, interval 1850ms.
Oct 07 13:12:15 testbed polkitd(authority=local)[533]: Operator of unix-session:2 FAILED to authenticate to gain authorization for action org.freedesktop.login1.suspend for system-bus-name::1.35 [xfce4-power-manager] (owned by unix-user:empty)
Oct 07 13:12:15 testbed pkexec[2126]: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
Oct 07 13:12:15 testbed pkexec[2126]: empty: Executing command [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backlight-helper --set-brightness 530]
Oct 07 13:12:15 testbed dbus[497]: [system] Rejected send message, 4 matched rules; type="method_call", sender=":1.34" (uid=1000 pid=1136 comm="xfce4-power-manager ") interface="org.freedesktop.NetworkManager" member="Sleep" error name="(unset)" requested_reply="0" destination="org.freedesktop.NetworkManager" (uid=0 pid=510 comm="/usr/sbin/NetworkManager --no-daemon ")
Oct 07 13:12:16 testbed dhclient[2116]: XMT: Info-Request on wlp2s0, interval 3600ms.
Oct 07 13:12:16 testbed systemd-logind[490]: Removed session c3.
-- Subject: Session c3 has been terminated
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- Documentation: http://www.freedesktop.org/wiki/Software/systemd/multiseat
-- 
-- A session with the ID c3 has been terminated.

The only problem with "KillUserProcesses=yes" is that it will also kill any tmux (or screen) sessions and may break other programs in subtle ways — there must be a reason why Debian turn that off, upstream supply systemd with that option enabled.

Last edited by johnraff (2017-10-17 02:21:56)

johnraff · 2017-10-09 08:08:54

Confirmed on my old Panasonic.

What I did:
power manager settings to suspend on lid close
close lid, laptop suspends
open lid, laptop wakes and I can login

BUT
close lid, laptop suspends
open lid, laptop wakes
close lid without logging in, laptop suspends
open lid, laptop wakes and I can login, but see the authentication message, and a (different) Power Manager warning.
Click "cancel" to carry on. The cancel button sometimes fails, but Esc closes it (sometimes needs two tries).

Another (single) time:
reboot, login screen displayed
close lid without logging in, laptop suspends
open lid, laptop wakes and I can login, BUT tint2 is missing! (No hints in .xsession-errors, BUT a lot of warnings about unusable config entries in tint2rc needing tint2 to be upgraded - a different issue of course.)

Head_on_a_Stick · 2017-10-09 20:10:18

@John, does setting KillUserProcesses=yes in /etc/systemd/logind.conf fix the problem?

I will try it myself next time I boot Helium-dev.

Last edited by johnraff (2017-10-17 02:22:23)

johnraff · 2017-10-10 07:32:03

Head_on_a_Stick wrote:

@John, does setting KillUserProcesses=yes in /etc/systemd/logind.conf fix the problem?

No, but I haven't tried installing accountsservice yet. Also just noticed that the new Debian upgrade hasn't been applied yet either, so now checking just in case that fixes it.

Last edited by johnraff (2017-10-17 02:22:49)

johnraff · 2017-10-10 07:54:31

Upgrade to Debian 9.2, install accountsservice, set KillUserProcesses=yes in /etc/systemd/logind.conf, reboot, problem persists.

johnraff · 2017-10-13 06:37:11

@Matt or @Has I don't know if this is the canonical solution, but I found allowing, via polkit, inactive users to suspend got rid of those messages on my laptop.

The password dialog box indicated that the action involved was org.freedesktop.login1.suspend and /usr/share/polkit-1/actions/org.freedesktop.login1.policy indicates that for that action inactive users need to authenticate, but active users do not.

So, I tried allowing inactive users to suspend too.
In /etc/polkit-1/localauthority/10-vendor.d/inactive-suspend.pkla:

[Allow inactive users to suspend]
Identity=unix-user:*
Action=org.freedesktop.login1.suspend
ResultInactive=yes
ResultActive=yes

(Purge accountsservice and restore that KillUserProcesses line to default.)
And reboot.
It worked with Identity=unix-user:john too, but not with Identity=unix-user:lightdm so the issue seems to be that after closing the lid and suspending, the user is no longer active. I don't know why that's no problem with a single lid close/open though.
EDIT: on rethought, it makes sort of sense. A current active user closes the lid. He's allowed to suspend. Later, opens the lid. If he then closes the lid without logging in, he's now inactive but the machine is suspended. (why? EDIT: could it be that after the inactive user's attempt to suspend has been refused - triggering the popups - then logind comes in and suspends anyway?) After finally logging in, the error message and password box are there (in my theory) from when the machine did its second suspend, not from after the login.

It must be a lightdm (or logind? or xfce4-power-manager?) bug. If the lid is closed with no-one logged in, what user is "responsible" for the suspend? lightdm? logind? I guess logind does the suspend. I do not get any errors when closing the lid after a fresh boot, ie with no user logged in, even without the above polkit fix.
OTOH, if a user is still logged in, but their screen is locked, then the suspend proceeds (I'm guessing) as by them, but they are inactive. (Hence, allowing inactive users to suspend "fixes" the issue.) The default permissions need to be changed, or lightdm/logind needs to do the suspends for inactive locked-out users itself... or maybe xfce4-power-manager needs to cease trying to suspend for inactive users, since logind can handle it anyway?

This fix could also be realized via a .rules file in /usr/share/polkit/rules.d if there was a reason for doing so, and there might well be a completely different better solution (via systemd?) but this seems to be doing the job for now.

Last edited by johnraff (2017-10-15 08:14:34)

Head_on_a_Stick · 2017-10-15 20:06:27

johnraff wrote:

/etc/polkit-1/localauthority/10-vendor.d/inactive-suspend.pkla

That file fixes the problem for me in a fresh installation, good work!

johnraff · 2017-10-16 06:14:50

The problem seems (AFAICT) to come from xfce4-power-manager trying to suspend the machine when a user is logged-in, but inactive (ie screen locked). What would it do, I wonder, if two users were in that state when the laptop lid was closed? Which user would be associated with the suspend request?

Anyway, since logind can suspend on lid closure with no user logged-in, I would have thought xfce4-power-manager ought to just leave it to logind for inactive users. There are a number of bug reports for x-p-m and suspend, but I haven't been able to find anyone raising this specific point.

The polkit hacktweak does fix the issue, but enables any inactive user to suspend the system. Might that be a security risk? We could focus in a little bit by giving the permission only to members of a group that only "normal" users belong to, eg 'mail cdrom floppy audio dip video plugdev systemd-journal netdev'. We were thinking of adding all BL users to systemd-journal by default, so we could use that? Alternatively, create a new group 'shutdown' and use that? ('shutdown' could be used to give everyone shutdown/reboot/suspend/etc permissions independently of systemd.)

Head_on_a_Stick · 2017-10-16 06:21:10

johnraff wrote:

security risk

Perhaps, yes.

We could just live with the error messages.

On a broader note: LightDM is not as secure as either GDM or no display manager at all under Debian stretch because the X server must be run as root under LightDM, this is a significant security risk and I strongly recommend that we either switch to GDM or drop the display manager entirely.

Last edited by Head_on_a_Stick (2017-10-16 06:21:24)

johnraff · 2017-10-16 07:19:14

Head_on_a_Stick wrote:

johnraff wrote:
security risk
Perhaps, yes.
We could just live with the error messages.

But that's messy. In that case, how about configuring adduser.conf to put all "real people" users in a "shutdown" group, and giving inactive suspend rights only to members? That would rule out all the other random linux users.

On a broader note: LightDM is not as secure as either GDM or no display manager at all under Debian stretch because the X server must be run as root under LightDM, this is a significant security risk and I strongly recommend that we either switch to GDM or drop the display manager entirely.

Dropping the DM is not an option for our user base, I think. Just from a visual POV it would make the first impression much harsher. (btw I think our forum membership is probably somewhat on the geekier side of the spectrum to our general user population.) Of course this is not something that changed with Debian Stretch. As far as I know, DMs have always been running X as root - I didn't know GDM had stopped.
EDIT: According to the Arch Wiki "display managers are not supported" for rootless X. Sorry, further down it says "GDM also runs Xorg without root privileges by default when Kernel mode setting is used" but it sounds rather difficult...

What was the reason we (or Philip) moved from GDM again?
[EDIT: Of course before LightDM #! used Slim. If GDM was ever used it would have been back in the Ubuntu-based days.]
Gnome apps have slimmed down a bit lately so it might be an option, but could well bring in a whole new collection of annoyances of its own...

Would you volunteer to make the substitution on a helium-dev system and report how it goes?
EDIT: It has a formidable list of dependencies: https://packages.debian.org/stretch/gdm3

Last edited by johnraff (2017-10-17 02:33:38)

Head_on_a_Stick · 2017-10-16 20:28:08

johnraff wrote:

Of course this is not something that changed with Debian Stretch. As far as I know, DMs have always been running X as root

The X server itself was adjusted (by the OpenBSD developers) so that it was able to be run by a normal user several years ago and GDM has had the capability since just after it became available.

See section 2.2.11 of the Debian stretch release notes for more on this:

https://www.debian.org/releases/stable/ … uires-root

I have changed from LightDM to a console login on my family Debian stretch laptop for precisely this reason and my (intensely technophobic) girlfriend actually prefers it

johnraff wrote:

Would you volunteer to make the substitution on a helium-dev system and report how it goes?

Gladly

To use the vernacular of the locals in my area:

I'm on it like a car bonnet

hhh · 2017-10-16 20:33:42

Head_on_a_Stick wrote:

I'm on it like a car bonnet

Quaint. Here, it's "On it like flies on shit."

Head_on_a_Stick · 2017-10-16 21:48:52

johnraff wrote:

make the substitution on a helium-dev system

It's horrific — even with --no-install-recommends it still pulls in ~70 packages and ~117MiB and that includes the GNOME shell itself

What's more, GDM(3) doesn't seem to work at all in my BL-He system, the screen just blinks a few times and then shows a (console) screen blank except for "Booting a command list" (this is a message from GRUB because I had to edit the kernel command line to boot with systemd) and a blinking cursor.

This usually means that kernel mode setting (KMS) needs to be disabled but the X server runs fine (and not as root) with plain `startx` and rootless X needs KMS to work

If I have broken this box in some way (likely) then it is a new b0rkage record because I only installed it a few days ago :cry:

Anyway, it's late now so I will have to look into this further on the morrow...

hhh · 2017-10-16 21:56:54

Let me see what happens on my system. On it like Xenia Onatopp was on Bond, A.K.A I'm Onatopp of it...

-edit- Gah! gnome-shell and gnome-session!!! They're out of mustard! Aaaaaa!!! German potato salad!
https://packages.debian.org/stretch/gdm3

Last edited by hhh (2017-10-16 22:00:35)

johnraff · 2017-10-17 03:22:30

hhh wrote:

Gah! gnome-shell and gnome-session!!! They're out of mustard! Aaaaaa!!! German potato salad!
https://packages.debian.org/stretch/gdm3

gnome-session is OK: x-session-manager, provided by openbox-session, is an alternative dependency. gnome-shell and friends though...

#1 2017-10-05 00:08:32

laptop suspend issues, and login/display_managers

#2 2017-10-05 01:40:02

Re: laptop suspend issues, and login/display_managers

#3 2017-10-06 08:17:30

Re: laptop suspend issues, and login/display_managers

#4 2017-10-06 19:42:13

Re: laptop suspend issues, and login/display_managers

#5 2017-10-07 07:24:37

Re: laptop suspend issues, and login/display_managers

#6 2017-10-07 13:05:37

Re: laptop suspend issues, and login/display_managers

#7 2017-10-09 08:08:54

Re: laptop suspend issues, and login/display_managers

#8 2017-10-09 20:10:18

Re: laptop suspend issues, and login/display_managers

#9 2017-10-10 07:32:03

Re: laptop suspend issues, and login/display_managers

#10 2017-10-10 07:54:31

Re: laptop suspend issues, and login/display_managers

#11 2017-10-13 06:37:11

Re: laptop suspend issues, and login/display_managers

#12 2017-10-15 20:06:27

Re: laptop suspend issues, and login/display_managers

#13 2017-10-16 06:14:50

Re: laptop suspend issues, and login/display_managers

#14 2017-10-16 06:21:10

Re: laptop suspend issues, and login/display_managers

#15 2017-10-16 07:19:14

Re: laptop suspend issues, and login/display_managers

#16 2017-10-16 20:28:08

Re: laptop suspend issues, and login/display_managers

#17 2017-10-16 20:33:42

Re: laptop suspend issues, and login/display_managers

#18 2017-10-16 21:48:52

Re: laptop suspend issues, and login/display_managers

#19 2017-10-16 21:56:54

Re: laptop suspend issues, and login/display_managers

#20 2017-10-17 03:22:30

Re: laptop suspend issues, and login/display_managers

Board footer