laptop suspend issues, and login/display_managers

hhh · 2017-10-17 05:09:16

^Right, that's what I saw, you have only one option. GNOME is now all seeing and all knowing.

Head_on_a_Stick · 2017-10-17 06:16:01

Yes, it doesn't really look practicable does it? Unless we want to try to ship a stripped-down, greyed-up GNOME desktop and hope nobody notices... ]:D

I suppose I'll just have to write a "drop the DM" HowTo then.

EDIT: it should be quite short anyway:

sudo systemctl set-default multi-user.target
tee -a ~/.profile << "!"
[ "$(tty)" = "/dev/tty1" ] && exec startx
!
reboot

Done!

Last edited by Head_on_a_Stick (2017-10-17 06:26:48)

johnraff · 2017-10-17 07:09:54

^I used to have this:

# start X automatically
if [ ! -f "$HOME"/.noAutoX ] && [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ]
then
    startx
fi

# --- after X closes (or isn't started) ---
# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
	. "$HOME/.bashrc"
    fi
fi

"$HOME"/.noAutoX is a flag I used to put in when I wanted to boot to a tty. (By a sort of login script triggered from getty.)
By leaving out the 'exec', .profile will be returned to after X closes, and the remaining code read (for Bash users in this case).
If you're going to allow multiple X sessions, then the $DISPLAY test won't be wanted (which goes back to your code).

johnraff · 2017-10-17 07:12:47

When corenominal dropped Plymouth I thought it was a step backwards, but the bootup screen goes by so fast these days it doesn't really matter. Maybe people would get used to a terminal login... (but let's not rush into this too soon)

Head_on_a_Stick · 2017-10-17 18:00:42

johnraff wrote:

^I used to have this:
# start X automatically
if [ ! -f "$HOME"/.noAutoX ] && [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ]
then
    startx
fi
"$HOME"/.noAutoX is a flag I used to put in when I wanted to boot to a tty.

Nice idea, I may steal that

Also, $DISPLAY will never be set if `tty` outputs "/dev/tty1" so that check is just slowing down your startup.

No need for the bashism either, as you can see from my version 8o

Last edited by Head_on_a_Stick (2017-10-17 18:18:09)

tknomanzr · 2017-10-17 20:04:27

Suspend issues in lightdm seem to be directly related to the issues I was having with accessibility issues some days ago. For reference:
https://forums.bunsenlabs.org/viewtopic.php?id=4243

The issues are related in that, control gets passed from user lightdm to the actual user on login but some services seem to not be understanding it. I am pointing this out because seeing the same type of error in two different contexts suggests to me that we probably do not entirely understand the implications of the various configuration options in lightdm. At least I know, I do not.

For example, setting xserver-share = false seemed to resolve my issues but I have no idea the implications that changing that would have. For myself, I feel like it is time to achieve some clarity on how to properly manage lightdm if I am going to continue to use it.

johnraff · 2017-10-18 02:52:40

Head_on_a_Stick wrote:

Also, $DISPLAY will never be set if `tty` outputs "/dev/tty1" so that check is just slowing down your startup.

Indeed - quick check - it isn't set on the other ttys. Of course the time is probably less than a millisecond, but as a matter of principle...

No need for the bashism either

...er what bashism? I think all the code I posted will run on a generic shell, no? Do you mean the sourcing of .bashrc? That's in the default Debian /etc/skel/.profile, and anyone running the OneShellToRuleThemAll would want it.

johnraff · 2017-10-18 03:35:47

tknomanzr wrote:

Suspend issues in lightdm seem to be directly related to the issues I was having with accessibility issues some days ago. For reference:
https://forums.bunsenlabs.org/viewtopic.php?id=4243
The issues are related in that, control gets passed from user lightdm to the actual user on login but some services seem to not be understanding it....

I'm not quite sure if this is a lightdm issue specifically - in this case it's about control being passed back to the login screen when a user suspends. Actually, this is something quite minor that most users won't see, it only appears if a laptop lid is closed when the login screen is being displayed, but a user is still logged in (but, of course, inactive).

This is only my current picture, which could be wrong, but based on evidence so far:
*) this error line posted by HoaS:

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)

*) the error which appears on the password dialogue:

org.freedesktop.login1.suspend

*) the default polkit setting:

        <action id="org.freedesktop.login1.suspend">
                <description>Suspend the system
                <message>Authentication is required for suspending the system.
                        <allow_any>auth_admin_keep
                        <allow_inactive>auth_admin_keep
                        <allow_active>yes

*) default logind setting in/etc/systemd/logind.conf:

HandleLidSwitch=suspend

So, I think this might be happening:

user is logged in, active desktop > closes lid > xfce4-power-manager initiates suspend > polkit grants permission (user is active)

open lid, user is logged in but inactive > log in via lightdm > OK
BUT IF
close lid again > xfce-power-manager tries to suspend for inactive user > permission refused, error messages set in user's inactive session
logind initiates suspend anyway

open lid again > log in > discover error messages set when lid was closed (they can just be harmlessly dismissed at this point)

TL:DR The problem is somewhere between lightdm, logind, and xfce4-power-manager. My personal feeling is that x-p-m is wrong to try to handle suspend for an inactive (locked screen) user. What if two users were in that state? It's quite possible. Which user would x-p-m use to initiate suspend? It should be left to logind when at the lightdm login/unlock screen IMO.

My proposed fix is to allow inactive users to suspend. This is definitely a workaround, but unless there is a config to keep x-p-m away from the login screen it might be the only way till upstream fixes it. I haven't yet been able to find any bug reports on this exact issue, although there are many for x-p-m on suspend issues in general.

Head_on_a_Stick · 2017-10-18 05:58:46

johnraff wrote:

...er what bashism?

Sorry, my mistake, for some reason I thought the form of check used for `tty` wasn't allowed under POSIX but I am clearly wrong about that.

Anyway, back on topic...

johnraff · 2017-11-11 01:51:59

https://forums.bunsenlabs.org/viewtopic.php?id=4361

Inactive user's laptop battery drained because xfce4-power-manager needed a password in order to shutdown.
Should we consider allowing, by default, inactive users to shutdown as well as suspend?

tknomanzr · 2017-11-11 02:53:10

If that is what is preventing the laptop from shutting down when the battery is low, I don't see a problem with that.

johnraff · 2017-11-12 02:52:30

^We don't yet know if adjusting the permissions that way actually fixed the no-shutdown problem, fingers crossed...

johnraff · 2017-12-07 03:27:10

New feedback indicates that allowing inactive users to power-off solves the low-battery-shutdown problem.
https://forums.bunsenlabs.org/viewtopic … 067#p65067

OK to go ahead and add this:

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

to /var/lib/polkit-1/localauthority/10-vendor.d/org.bunsenlabs.pkla ?

tknomanzr · 2017-12-07 05:18:10

I don't see a problem with that.

johnraff · 2017-12-08 03:21:14

If no-one objects in a day or so I'll add it to bunsen-configs for Helium.

johnraff · 2017-12-10 06:23:16

Committed, not yet packaged.

#21 2017-10-17 05:09:16

Re: laptop suspend issues, and login/display_managers

#22 2017-10-17 06:16:01

Re: laptop suspend issues, and login/display_managers

#23 2017-10-17 07:09:54

Re: laptop suspend issues, and login/display_managers

#24 2017-10-17 07:12:47

Re: laptop suspend issues, and login/display_managers

#25 2017-10-17 18:00:42

Re: laptop suspend issues, and login/display_managers

#26 2017-10-17 20:04:27

Re: laptop suspend issues, and login/display_managers

#27 2017-10-18 02:52:40

Re: laptop suspend issues, and login/display_managers

#28 2017-10-18 03:35:47

Re: laptop suspend issues, and login/display_managers

#29 2017-10-18 05:58:46

Re: laptop suspend issues, and login/display_managers

#30 2017-11-11 01:51:59

Re: laptop suspend issues, and login/display_managers

#31 2017-11-11 02:53:10

Re: laptop suspend issues, and login/display_managers

#32 2017-11-12 02:52:30

Re: laptop suspend issues, and login/display_managers

#33 2017-12-07 03:27:10

Re: laptop suspend issues, and login/display_managers

#34 2017-12-07 05:18:10

Re: laptop suspend issues, and login/display_managers

#35 2017-12-08 03:21:14

Re: laptop suspend issues, and login/display_managers

#36 2017-12-10 06:23:16

Re: laptop suspend issues, and login/display_managers

Board footer