Red Hat Bugzilla – Bug 1261440
Computer went to sleep but screen lock was inhibited?
Last modified: 2016-07-19 13:50:11 EDT
Description of problem:
I put my computer to sleep.[*]
When I resumed, I had a new notification (GNOME-style toaster) that said screen lock had been inhibited by an application. (Didn't say which one).
*I do not recall having to enter my password on resume*.
[*] By shutting the lid. I believe this was immediately after logging in, after a reboot-and-install-updates. Unfortunately I can't find what the updated packages were.
Version-Release number of selected component (if applicable):
I'm reporting this immediately, as an apparent logic error that this can ever happen.
Steps to Reproduce: unknown
- notification warning about inhibited screen-lock on resume
- AFAIR the screen-lock was genuinely inhibited, such that I did not have to enter a password
- System sleep should always lock active sessions (unless user has tampered with defaults).
- If we then ignore a lock-inhibit in the process, that's fine. There would be no notification to the user about it; it's just not needed.
- It's also a pity that the notification didn't show any information about what had blocked the screen-lock.
Note that systemd inhibits do a great job of explaining themselves (in systemd-inibit --list). I know GNOME app inhibits aren't the same thing, but it's a pity the notification wasn't able to name the app responsible :).
I didn't have any windows open or anything really. The source of the inhibit is a bit mysterious.
- Hopefully apps consider whether they just want to stop screenlock-on-timeout, or if they need to stop user-initiated sleep as well. So it won't matter that the screen is getting locked on sleep, even though some app requested a screen-lock inhibit.
(In reply to Alan Jenkins from comment #0)
> Description of problem:
> I put my computer to sleep.[*]
> When I resumed, I had a new notification (GNOME-style toaster) that said
> screen lock had been inhibited by an application. (Didn't say which one).
Did it actually say "Lock was blocked by an application" ? That actually means that an application was holding onto a grab, and gnome-shell couldn't show the screen shield.
> Actual results:
> - notification warning about inhibited screen-lock on resume
Blocked, not inhibited.
> - AFAIR the screen-lock was genuinely inhibited, such that I did not have to
> enter a password
There's no screen lock inhibition in GNOME, or systemd. There's an idle inhibition though.
> it's a pity the notification wasn't able to name the app responsible :).
Unfortunately the thing that's blocking screen locking is doing it at the X server level, in a way that gnome can't stop, and the x server doesn't provide a nice mechanism for querying the responsible client.
Right, thanks for your expert help! It didn't say inhibited - that was my word.
It did explicitly say ~"by an application". "blocked" sounds about right; I don't know the exact wording though.
So from what you're saying
- There's no evidence for a bug in g-s-d specifically.
- We'd need to see it reproduced with specific steps, then find where the X grab is somehow.
- Maybe forget this happened unless it reoccurs. Wayland will change everything anyway :).
(In reply to Alan Jenkins from comment #3)
> Right, thanks for your expert help! It didn't say inhibited - that was my
> It did explicitly say ~"by an application". "blocked" sounds about right; I
> don't know the exact wording though.
> So from what you're saying
> - There's no evidence for a bug in g-s-d specifically.
There's no bug in g-s-d at all.
> - We'd need to see it reproduced with specific steps, then find where the X
> grab is somehow.
You'd need to find which application was at fault, indeed. Could be an opened menu in Firefox, or an SDL game running.
> - Maybe forget this happened unless it reoccurs. Wayland will change
> everything anyway :).
Wayland will certainly avoid the screen shield not showing up.
Reassigning to gnome-shell for that confusing error message.
I understand it might be caused by those things, but I hadn't started any apps. Maybe it was a race condition, i.e. a brief grab during session startup.
I said no specific evidence for g-s-d, and it would sound odd. However it's one of the (always) running programs that uses X, so it's among the candidates.
Personally I'm not sure how to improve the message. I think the most important thing is to blame an application, which it does. Some people won't know what "lock" means. But if the missing screenlock matters to them, it should be fairly clear from the context.
I'm actually quite impressed by the error message (at least that it appears at all :).
If people want to reproduce the error message: Maybe try the old gtk newsreader, "pan". pan's File menu blocks screenlock during suspend (as well as alt+tab). I think Firefox stopped using grabs for menus (at least global shortcuts like alt+tab work, which is cool).
(In reply to Alan Jenkins from comment #5)
> Personally I'm not sure how to improve the message. I think the most
> important thing is to blame an application, which it does.
It is a shot in the dark as we don't know the actual culprit, however it's the most likely cause and less gibberish than "Something in your session holds a grab and prevents the screen from locking".
So I'm not sure either how to do better there ...
not sure, but we might be able to get an educated guess from XGetInputFocus
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.