Bug 1476313 - After `systemctl mask suspend.target`, attempting to suspend switches my graphical VT session to text mode
After `systemctl mask suspend.target`, attempting to suspend switches my grap...
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2017-07-28 11:32 EDT by Alan Jenkins
Modified: 2017-11-10 22:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-11-10 22:06:35 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alan Jenkins 2017-07-28 11:32:38 EDT
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):


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 09:44:40 EDT
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 11:47:13 EDT
https://github.com/systemd/systemd/pull/6666 has been merged.
Comment 3 Fedora Update System 2017-10-26 09:16:00 EDT
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 14:49:11 EDT
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-10 22:06:35 EST
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.