After setting the screensaver lock timeout to 10 minutes, waiting 10 minutes, and then activating the screen, the password entry does not allow text input and the user is locked out. Demonstration: https://www.youtube.com/watch?v=tUqdmKIucbM To reproduce, use this Docker image: https://hub.docker.com/r/kgibm/fedorawasdebug 1. Note: You'll need more than 20GB of disk space and configure Docker with 4GB or more of RAM. For detailed instructions, see the Lab PDF at https://raw.githubusercontent.com/kgibm/dockerdebug/master/fedorawasdebug/WebSphere_Application_Server_Troubleshooting_and_Performance_Lab_on_Docker.pdf 2. docker run --cap-add SYS_PTRACE --ulimit core=-1 --ulimit memlock=-1 --ulimit stack=-1 --shm-size="256m" --rm -p 9080:9080 -p 9443:9443 -p 9043:9043 -p 9081:9081 -p 9444:9444 -p 5901:5901 -p 5902:5902 -p 3390:3389 -p 22:22 -p 9082:9082 -p 9083:9083 -p 9445:9445 -p 8080:8080 -p 8081:8081 -p 8082:8082 -p 12000:12000 -p 12005:12005 -it kgibm/fedorawasdebug 3. The container is fully started after about 2 minutes when the output shows: = READY = 4. Remote into the docker image with password 'websphere' (no quotes). Linux: vncviewer localhost:5902. Mac: open vnc://localhost:5902. Windows: Remote desktop (see lab instructions), or use a free VNC client. 5. Open Settings > Screensaver and change the timeout to 10 minutes 6. Idle for 10 minutes 7. Activate the screen 8. Try to type in the password 'websphere' (no quotes) but typing does not work. 9. User is locked out. The image is built using the following three layers of Dockerfiles (instructions on how to build each Dockerfile are in comments at the top of the Dockerfile): 1. Fedora image: https://github.com/kgibm/dockerdebug/blob/master/fedoradebug/Dockerfile 2. Java image: https://github.com/kgibm/dockerdebug/blob/master/fedorajavadebug/Dockerfile 3. Final image: https://github.com/kgibm/dockerdebug/blob/master/fedorawasdebug/Dockerfile For those unfamiliar with Docker, if you want to debug the issue after it occurs, you may "login" to the running container using: docker ps Take the container ID and then: docker exec -it $containerid bash
Key events in the YouTube video: 1. 0:07 - First starting with a 1 minute idle timeout: https://youtu.be/tUqdmKIucbM?t=7 2. 1:24 - Activating the screen after a minute works: https://youtu.be/tUqdmKIucbM?t=84 3. 1:36 - Change to 5 minute idle timeout: https://youtu.be/tUqdmKIucbM?t=96 4. 6:56 - Activating the screen after 5 minutes works: https://youtu.be/tUqdmKIucbM?t=416 5. 7:08 - Change to 10 minute idle timeout: https://youtu.be/tUqdmKIucbM?t=428 6. 17:23 - Activating the screen after 10 minutes does not work: https://youtu.be/tUqdmKIucbM?t=1043
This is caused by xscreensaver locking at 10 minutes (as seen by `xset q`). Worked around the problem with the following (not installing xscreensaver* didn't help as something seems to bring it in as a dependency): rm -rf /etc/xdg/autostart/xscreensaver*
Note that the reproduction noted above will no longer work as I pushed a new version of the image into DockerHub with the fix in comment 2; however, the problem should be easily reproducible by simply installing both xscreensaver and xfce4-screensaver.
im not sure what to with this problem. The only possible workaround here is not to start xfce4-screensaver daemon if xscreensaver is detected. what is the point of having both xscreensaver and xfce4-screensaver running?
(In reply to Alexander Butenko from comment #4) > im not sure what to with this problem. The only possible workaround here is > not to start xfce4-screensaver daemon if xscreensaver is detected. > what is the point of having both xscreensaver and xfce4-screensaver running? Not installing xscreensaver* didn't help as something seems to bring it in as a dependency. I had to explicitly do $(rm -rf /etc/xdg/autostart/xscreensaver*). I think it would be nice if xfce4-screensaver protected itself from this situation because it was very hard to figure out and of course a completely locked screen is pretty scary.
It seems that similar bug can be triggered when light-locker is running in parallel with xfce4-screensaver, see https://bugs.launchpad.net/xfce4-screensaver/+bug/1875025. I'm afraid that this will cause problems for people upgrading from Xubuntu 18.04, where light-locker was installed by default AFAIK.
(In reply to Alexander Butenko from comment #4) > im not sure what to with this problem. The only possible workaround here is > not to start xfce4-screensaver daemon if xscreensaver is detected. > what is the point of having both xscreensaver and xfce4-screensaver running? I think that is OK, although it would make xfce4-screensaver susceptible to being disabled by creating a dummy xscreensaver/light-locker process. On the other hand, it can be killed by any user process anyway. Disclaimer: I don't know xfce or screensaver internals.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/25. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev