Bug 1476313 - After `systemctl mask suspend.target`, attempting to suspend switches my graphical VT session to text mode
Summary: After `systemctl mask suspend.target`, attempting to suspend switches my grap...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-28 15:32 UTC by Alan Jenkins
Modified: 2017-11-11 03:06 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-11-11 03:06:35 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Alan Jenkins 2017-07-28 15:32:38 UTC
Description of problem:

If I specifically run `systemctl mask suspend.target`, then attempting to suspend seems to switch my graphical VT session to text mode.

I don't mean it changes from VT2 to a different VT.  I mean I'm on VT2, but after attempting to suspend VT2 does not show graphics any more.  gdm is affected too.  But my processes e.g. firefox are still running.

The weird thing is this doesn't happen if try suspending with `systemd-suspend.service` set to use `ExecStart=/bin/false` instead.


Version-Release number of selected component (if applicable):

    systemd-233-6.fc26.x86_64
    gnome-shell-3.24.3-1.fc26.x86_64
    libwayland-server-1.13.0-1.fc26.x86_64

How reproducible: always

Steps to Reproduce:

    $ sudo systemctl mask suspend.target
    $ sudo systemctl suspend

Actual results:

This switches me to a text VT.  I can't get back to gdm - VT1 shows the textual boot messages.  I can't get back to my desktop session, VT2 just shows `^@^@^@...` (like [here](https://unix.stackexchange.com/questions/360830/whats-nul-bombing-my-console-during-shutdown)).  `w` still showed me logged in on `tty2`, and `ps` showed my firefox process was still running.

Expected results:

Suspend should fail, but I should see the graphical lock screen and be able to get back into my desktop session.

Comment 1 Alan Jenkins 2017-08-24 13:44:40 UTC
I tried reproducing this inside a VM.

In this case, the graphical screen remained (without a lock screen), but keyboard input was blocked (I think mouse blocked as well).  Switching to a different VT and back showed a lock screen and un-blocked input.

This is a bug in logind, that it doesn't send a "resume" (PrepareToSleep false) signal in this case.  I can say this with confidence because patching logind resolved the problem :).  At least inside the VM.  I'm sending a PR upstream which references this bug.

Note: kernel 4.12.5-300 fails to resume with QXL, generating a backtrace visible only if booted with `no_console_suspend`.  Reverting to 4.11.11-300 got it working again.

Comment 2 Alan Jenkins 2017-09-13 15:47:13 UTC
https://github.com/systemd/systemd/pull/6666 has been merged.

Comment 3 Fedora Update System 2017-10-26 13:16:00 UTC
systemd-234-9.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6263c938c7

Comment 4 Fedora Update System 2017-10-27 18:49:11 UTC
systemd-234-9.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-6263c938c7

Comment 5 Fedora Update System 2017-11-11 03:06:35 UTC
systemd-234-9.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.