Description of problem: LXDE locks the screen even if xscreensaver is turned off. I think it uses either xlock or i3lock. The man page for lxlock gives an ordered list, and xscreensaver is before those, so lxlock should not reach them when it finds xscreensaver set to disabled. Version-Release number of selected component (if applicable): lxde-common-0.99.2-15.fc35.noarch How reproducible: Always. Steps to Reproduce: 1. Run LXDE 2. Have an alternate screen locker installed, disable xscreensaver 3. Wait a few minutes, LXDE locks the screen Actual results: Locked screen Expected results: Screen never locks. Additional info:
Please write the exact procedure so that I can reproduce the issue from the report. * Are you trying from fresh install? If so, please write the media you tried. * Please write the detail what "Have an alternate screen locker installed" "disable xscreensaver" mean.
Yes, it was a fresh rawhide install from the network install image. I used a CD, with the server install dvd as the source. Because of the way I have my router configured to use non-standard DNS servers, I could not get the repositories to work. That has been resolved now, and I am able to update from the Fedora repositories. I installed LXDE from the Fedora repositories, along with many other programs. I have also updated to the latest available programs in the repositories. When I use the fedora menu in LXDE (preferences -> screensaver) to bring up the xscreensaver application, it shows 'Disable Screen Saver' as the active mode. I also have xlock and i3lock installed. The man page for lxlock says: lxlock is a simple script to lock the session, using third application. It currently those applications, in this order (try the next one if the application is not available) : light-locker xscreensaver gnome-screensaver slock xlock i3lock Of those, only xscreensaver, xlock, and i3lock are installed.
So you have invoked "lxlock" manually or have configured so that lxlock is launched after a few minutes?
No, I just assumed that lxlock runs by default from within the LXDE desktop on a periodic basis. When I looked, there was no configuration file for lxlock. I have run LXDE for a long time, and never had anything to do with lxlock. This has always just worked; if xscreensaver is on, it activates, if it is off, nothing happens.
Ahh..... So this is now reproducible to me, but... it is found that this is a bug in xscreensaver 6.0x.. Looking at the code of xscreensaver.c, it looks like it does not check p->mode (while xscreensaver 5.45 did check if) when trying to blank.
Thanks! That was a very fast resolution of the problem, especially when the problem is in another package. Sorry for the noise.
FEDORA-2021-e2d51a516a has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e2d51a516a
FEDORA-2021-e2d51a516a has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e2d51a516a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e2d51a516a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Thanks for your quick response and fast turnaround. I installed the packages from koji, xscreensaver-base-6.01-2.fc35.x86_64 xscreensaver-extras-6.01-2.fc35.x86_64 xscreensaver-extras-base-6.01-2.fc35.x86_64 xscreensaver-extras-gss-6.01-2.fc35.x86_64 xscreensaver-gl-base-6.01-2.fc35.x86_64 xscreensaver-gl-extras-6.01-2.fc35.x86_64 xscreensaver-gl-extras-gss-6.01-2.fc35.x86_64 But the issue is still there. The screen still locks. I tried changing the xscreensaver setting to blank screen only with a long timeout, but the screen still locks. It is as if lxde is ignoring the settings in xscreensaver. I will wait for another lockup and see if I can find the screen locker in effect from a virtual console with ps alx | grep lock.
Looking for lock didn't find anything. But using a search for save found the xscreensaver running from lxde, it found xscreensaver-systemd, and it found xfce4-screensaver. I'm not sure why that last is running. I wonder if it is the source of the problem. It says it is started by process 1, which is systemd I think. I didn't start it, so it is something else starting it. It is in /etc/xdg/autostart, but so are all the other desktop screensavers, and they don't start. I killed it, will wait to see if that makes a difference. $ ps alx | grep -i save 0 9999 5138 4772 20 0 13784 3556 - S ? 0:07 xscreensaver -no-splash 0 9999 5534 5138 20 0 7844 3576 - S ? 0:00 xscreensaver-systemd 0 9999 6481 1 20 0 406100 24648 - Sl ? 0:01 /usr/bin/xfce4-screensaver Yes, that seems to have made the difference. The screen is no longer locking with xscreensaver turned off. I think this ticket can be closed. I'm not sure if there was even a problem in the first place, other than the fact that something is starting xfce4-screensaver. $ ps alx | grep -i save 0 9999 5138 4772 20 0 13784 3496 - S ? 0:08 xscreensaver -no-splash 0 9999 5534 5138 20 0 7844 3536 - S ? 0:00 xscreensaver-systemd If there wasn't a problem, I apologize for the noise. Thank you for your help.
Routing this to the xfce4-screensaver component. It seems there is something wrong with the configuration of this component, as it is being started by systemd when XFCE is not running. No other desktop screensavers are doing this. It seems to be started when X is started. This might not be noticed usually because X is started with a specific desktop, like XFCE, so it wouldn't be noticed. In my case, I boot to runlevel multiuser, and manually start the desktop with a script that takes the place of the greeter that would greet people booting to a GUI. So, when I start X with LXDE, the xfce4-screensaver is started, thinking that XFCE is going to run, when it isn't.
Simple workaround. There is a program xfce4-screensaver-preferences, and it can be used to turn the xfce4-screensaver off.
FEDORA-2021-e2d51a516a has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.