New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Screen locks randomly #3727

Open
shunju opened this Issue Mar 21, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@shunju

shunju commented Mar 21, 2018

Qubes OS version:

R4.0-rc4, RC4.0-rc5

Affected component(s):

Something in dom0


Steps to reproduce the behavior:

Work at the computer for a long amount of time.

Expected behavior:

Screen never locks while user is actively using the computer.

Actual behavior:

Sometimes, out of the blue, seemingly randomly, the screen will lock. Screen lock window gives feedback and unlocks screen when correct password is provided.

General notes:

The mouse can only move inside the X screensaver window, moving the mouse or typing any keys (including Alt+Tab, Strg+Alt+Left, Strg+Alt+Right, …) does not redraw the screen.

I have a feeling that this issue is getting worse (happens more often recently), but that is hopefully just my imagination. I have searched /var/log/X.org.0.log and ~/.xsession-errors, but haven’t found anything conspicuous. I will try to remember to capture and provide logs as requested when the issue occurs again.


Related issues:

Maybe #2399 is related. However, in contrast to #2399, the screen is in fact locked in the present issue.

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 21, 2018

Member

See journalctl in dom0, maybe it's related to some problem with time synchronization (when time catch up, xscreensaver might think that inactivity timeout just elapsed, in seconds).

When screen is locked, are other windows visible, or are blacked out?

Member

marmarek commented Mar 21, 2018

See journalctl in dom0, maybe it's related to some problem with time synchronization (when time catch up, xscreensaver might think that inactivity timeout just elapsed, in seconds).

When screen is locked, are other windows visible, or are blacked out?

@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong Mar 22, 2018

Member

I think I might have experienced this on 3.2. In my case, it seems to happen at most once per reboot (but usually not at all), shortly after first booting and logging in.

Member

andrewdavidwong commented Mar 22, 2018

I think I might have experienced this on 3.2. In my case, it seems to happen at most once per reboot (but usually not at all), shortly after first booting and logging in.

@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong Mar 22, 2018

Member

@shunju, you didn't say which DE you're using, so I've assumed it's Xfce4. Let me know if it's a different one.

Member

andrewdavidwong commented Mar 22, 2018

@shunju, you didn't say which DE you're using, so I've assumed it's Xfce4. Let me know if it's a different one.

@Aekez

This comment has been minimized.

Show comment
Hide comment
@Aekez

Aekez Jul 22, 2018

I have an acquaintance (also on Qubes), who once had a similar problem like this (Xfce4, XScreenSaver, Qubes 4.0. some months back).

I found a fix for him by outright disabling XScreenSaver by clicking the "Disable Screen Saver" in the Mode: dropdown menu in XScreenSaver settings.

  • He no longer had the issue after fully disabling the countdown timer.
    • He still enables it manually when absent though (i.e. by ctrl+alt+L).
  • His problem was a bit different but similar.
    • It didn't happen when Qubes was used, but instead it didn't respect the inactivity countdown timer.
    • For example, despite setting it to the max 720 minutes, it still occured "at times" within an hour at the very least, despite having the setting to last 12 hours (720/60) of computer inactivity.
  • It never happened for him while he was using Qubes, but the 720 minute count didn't wait for 12 hours, but instead sometimes randomly happened in-between when inactive (i.e. when streaming movie, but Qubes keyboard/mouse/etc. input was untouched).

I have not observed it on my own Qubes system. However I also disable the XScreenSaver inactivity countdown my self, and instead made it a habit to manually log screen when absent, or manually trigger it with suspend mode instead. So I don't think I can encounter the bug anyway given the countdown timer is disabled, but this is only a deduction based on an anecdotal observation.


Whether this bug still happens, I'm not sure, it's been some months now. If its still around, maybe it'll go away on its own once dom0 is updated to fc26+ or never XScreensaver version in dom0 fc25?

Aekez commented Jul 22, 2018

I have an acquaintance (also on Qubes), who once had a similar problem like this (Xfce4, XScreenSaver, Qubes 4.0. some months back).

I found a fix for him by outright disabling XScreenSaver by clicking the "Disable Screen Saver" in the Mode: dropdown menu in XScreenSaver settings.

  • He no longer had the issue after fully disabling the countdown timer.
    • He still enables it manually when absent though (i.e. by ctrl+alt+L).
  • His problem was a bit different but similar.
    • It didn't happen when Qubes was used, but instead it didn't respect the inactivity countdown timer.
    • For example, despite setting it to the max 720 minutes, it still occured "at times" within an hour at the very least, despite having the setting to last 12 hours (720/60) of computer inactivity.
  • It never happened for him while he was using Qubes, but the 720 minute count didn't wait for 12 hours, but instead sometimes randomly happened in-between when inactive (i.e. when streaming movie, but Qubes keyboard/mouse/etc. input was untouched).

I have not observed it on my own Qubes system. However I also disable the XScreenSaver inactivity countdown my self, and instead made it a habit to manually log screen when absent, or manually trigger it with suspend mode instead. So I don't think I can encounter the bug anyway given the countdown timer is disabled, but this is only a deduction based on an anecdotal observation.


Whether this bug still happens, I'm not sure, it's been some months now. If its still around, maybe it'll go away on its own once dom0 is updated to fc26+ or never XScreensaver version in dom0 fc25?

@kototama

This comment has been minimized.

Show comment
Hide comment
@kototama

kototama Jul 26, 2018

I can confirm this bug and the explanation of Marmarek

when time catch up, xscreensaver might think that inactivity timeout just elapsed, in seconds

looks like a good one because it happens at the full hour for me, for example at 10:00 and I also have time synchronization issue: XFCE displays the UTC time after I boot instead of the local time and then resynchronize later.

I can confirm this bug and the explanation of Marmarek

when time catch up, xscreensaver might think that inactivity timeout just elapsed, in seconds

looks like a good one because it happens at the full hour for me, for example at 10:00 and I also have time synchronization issue: XFCE displays the UTC time after I boot instead of the local time and then resynchronize later.

@Aekez

This comment has been minimized.

Show comment
Hide comment
@Aekez

Aekez Jul 26, 2018

@kototama
That makes sense. Whether it's a coincidence or related, my acquaintance who had untimely locked screens also has time sync issues. I never heard whether it was at full round hours though, but it would certainly explain why only some people seem to get this bug, I presume.

Should this issue stay open if it can be verified to be associated and triggered by another bug/issue?

Aekez commented Jul 26, 2018

@kototama
That makes sense. Whether it's a coincidence or related, my acquaintance who had untimely locked screens also has time sync issues. I never heard whether it was at full round hours though, but it would certainly explain why only some people seem to get this bug, I presume.

Should this issue stay open if it can be verified to be associated and triggered by another bug/issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment