[SOLVED] Black screen after screenlock, cannot unlock and have to REISUB - what could be causing it?

Didier Spaier · 02-02-2018, 08:49 AM

Quote:

Originally Posted by Lysander666

There is something in what you say. If everything is done natively in LXDE it's fine [i.e. using LXDE stock applications] but if I use third-party applications [e.g. physlock] or Xfce Power Manager to do the job of suspend/lock, it can create issues. This is unusual since in Debian I was using LXDE with Xfce Power Manager and I never had an issue on this netbook. However, Debian has an official version of LXDE, Slackware does not [even though ponce's version of LXDE is excellent].

Slint includes LXDE (our own build) and xlockmore-5.46-x86_64-1.txz from Slackware and xscreensaver-5.37-x86_64-1_slack14.2 from Slackware in /patches. This works perfectly. Generally speaking, avoid replacing blindly a component by another one without a real need and a good rationale, at least without heavy testing, as this is a receipt for failure. Like replacing a card in a house of cards.

PS Here is the script lxlock executed when you click Screen Lock in the panel of LXDE (found in the lxsession-0.53 source archive):

Code:

#!/bin/sh
#
#
#  Copyright (C) 1999, 2003 Olivier Fourdan (fourdan@xfce.org)
#  Copyright (C) 2012 Julien Lavergne (gilir@ubuntu.com)
#  Copyright (C) 2013 Jarno Suni (8@iki.fi)
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#  along with this program; if not, write to the Free Software
#  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
#  MA 02110-1301, USA.

# Try to lock the screen with thos applications (in this order) :
# light-locker-command, xscreensaver, gnome-screensaver, slock, xlock, i3lock and xdg-screensaver

if pidof light-locker >/dev/null; then
    light-locker-command -l >/dev/null 2>&1
elif pidof xscreensaver >/dev/null; then
    xscreensaver-command -lock >/dev/null 2>&1
elif pidof gnome-screensaver >/dev/null; then
    gnome-screensaver-command --lock
elif which slock >/dev/null 2>&1; then
    slock &
elif which xlock >/dev/null 2>&1; then
    xlock $*
elif which i3lock >/dev/null 2>&1; then
    i3lock -d
elif which slimlock >/dev/null; then
    slimlock
else
    # In the end, try to fallback to xscreensaver

    # assert: gnome-screensaver is not running
    xscreensaver -nosplash >/dev/null 2>&1 &
    xscreensaver-command -lock >/dev/null 2>&1
fi
exit 0

As you can see the lockers you listed are not tried so if you removed those mentioned in the script that could be the cause of your issue.

If you have a full Slackware installation and no additional screen locker, as you can see xscreensaver will be preferred (xlock is shipped in lockmore).

Lysander666 · 02-02-2018, 10:26 AM

Thank you very much for the script and the clarification. I would like to address something though:

Quote:

Originally Posted by Didier Spaier

Generally speaking, avoid replacing blindly a component by another one without a real need and a good rationale, at least without heavy testing, as this is a receipt for failure.

I understand what you're saying about conflicts, but could not a real need just be preference? Especially in Linux when there is so much choice. I know that there can be too much choice, to an extent. But as long as testing or research is done, surely preference can be a good enough rationale?

Quote:

Originally Posted by Didier Spaier

Like replacing a card in a house of cards.

I'm not sure this is the best analogy - a house of cards is something fragile and unstable - not representative of the rock-like solidity of Slackware that has oft been discussed here. Maybe a better analogy could be the voluntary upgrading of computer components - some research has to be done beforehand, but if done correctly the user can experience a worthwhile upgrade with visible and measurable performance benefits. Conversely, if done wrongly, the user will experience a reduction in functionality and, in some cases, an altogether non-working system.

Didier Spaier · 02-02-2018, 10:46 AM

Quote:

Originally Posted by Lysander666

I understand what you're saying about conflicts, but could not a real need just be preference? Especially in Linux when there is so much choice. I know that there can be too much choice, to an extent. But as long as testing or research is done, surely preference can be a good enough rationale?

Yes, if you do the research and testing. As an example, let's imagine that you'd want all screen lockers in Slackware replaced by another one. How do you identify all the apps that could fail because of this replacement?

Quote:

I'm not sure this is the best analogy - a house of cards is something fragile and unstable - not representative of the rock-like solidity of Slackware that has oft been discussed here. Maybe a better analogy could be the voluntary upgrading of computer components - some research has to be done beforehand, but if done correctly the user can experience a worthwhile upgrade with visible and measurable performance benefits. Conversely, if done wrongly, the user will experience a reduction in functionality and, in some cases, an altogether non-working system.

If you have the specs of all your computer's interfaces and components you are lucky. But Slackware is in no way a system in which you can freely replace a component by another one, not thinking about then checking the consequences.

In other words Slackware is rock solid as long as you don't modify it and believe me, it costs the Slackware team a lot of knowledge, thinking and work to get this result. If you modify it, then it can behave like a house of cards. I am not saying that you can't modify it, of course. But you should be prepared to deal with adverse consequences if they occur.

Lysander666 · 02-02-2018, 10:49 AM

Quote:

Originally Posted by Didier Spaier

Yes, if you do the research and testing. In this case, let's imagine that you'd want all screen lockers in Slackware replaced by another one. How do you identify all the apps that could fail because of this replacement?

If you have the specs of all your computer's interfaces and components you are lucky. But Slackware is in no way a system in which you can freely replace a component by another one, not thinking about then checking the consequences.

In other words Slackware is rock solid as long as you don't modify it and believe me, it costs the Slackware team a lot of knowledge, thinking and work to get this result. If you modify it, then it can behave like a house of cards. I am not saying that you can't modify it, of course. But you should be prepared to deal with adverse consequences if they occur.

OK nicely put. Thank you.

Lysander666 · 02-03-2018, 02:31 PM

I am getting errors in xscreensaver on logout on the VM but I'm not too worried about that.

However, on logout on my main Slack install I noticed this error message that xauth does not exist. This message I presume appears when starting x but goes away too quickly to see.

X still starts fine though, so it's a bit confusing - is this anything to be concerned about?

Didier Spaier · 02-03-2018, 02:40 PM

Quote:

Originally Posted by Lysander666

X still starts fine though, so it's a bit confusing - is this anything to be concerned about?

Not at all. As an aside it's a little more annoying in Slint if speech is enabled because then the user hear this message just after having typed startx, although if speech is enabled I redirect the output of startx like this:

Code:

alias startx="/usr/bin/startx 1> .startx_output 2>.startx_errors"

Not the end of the world, though.

Lysander666 · 02-05-2018, 05:15 AM

Good to know, thanks, Didier. So is it normal for there to be such messages [I take it from your post it is]?

Didier Spaier · 02-05-2018, 05:46 AM

Quote:

Originally Posted by Lysander666

Good to know, thanks, Didier. So is it normal for there to be such messages [I take it from your post it is]?

Yes. This has been answered several times in this forum, see e.g. this post from Gazl.

Lysander666 · 02-05-2018, 05:59 AM

Quote:

Originally Posted by Didier Spaier

Yes. This has been answered several times in this forum, see e.g. this post from Gazl.

Good link. So not really an issue, so I see. However bass says

Quote:

If .Xauthority is not writeable, you probably started a program or X session as root using su from your normal user and screwed up permissions in your home directory. Try doing chown -R Fibonacchoz:users /home/Fibonacchoz (replacing Fibonacchoz with your normal username).

Now I absolutely always use su to install packages as a normal user. This is not the same thing though. But I'm starting to wonder whether I should be using "su" or "su -" as a normal user before installing a package.

EDIT: su seems to be fine http://insyte.atspace.com/installingprograms.html

Didier Spaier · 02-05-2018, 06:38 AM

Quote:

Originally Posted by Lysander666

EDIT: su seems to be fine http://insyte.atspace.com/installingprograms.html

Be cautious with the information you find on Internet, it should never be blindly trusted. In this case the website you linked to has not been updated since 13 years. For Slackware, better consult first https://docs.slackware.com/

And even though it doesn't hurt to use su to install a Slackware package, using su - is generally safer and can be used as well. So my advice is to always use su - for at least these two reasons:

You will not write in users' directories, at least not inadvertently.
Some commands will fail running su because the environment variables are then set for a regular user, not for root. As an example this makes running some SlackBuilds fail.