0

I don't know why, but until recently this command no longer works:

root# exec systemctl suspend

The system does try to suspend, with the screen even momentarily going off, but then it comes right back to the login prompt, so something is preventing suspension.

The system is a laptop with it's lid always closed (it's been like that for years). Because the lid is always closed, the following two entries were added years ago to accommodate that:

# /etc/systemd/logind.conf

[Login]
# ===========================================================
# VIA: https://unix.stackexchange.com/a/460405/103956
# ===========================================================
HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore
# ===========================================================

I'm just mentioning that for completeness.

Below is more information.

Any ideas friends? Thank you in advance. =:)

Linux g750asus 5.13.12-100.fc33.x86_64 #1 SMP Wed Aug 18 20:12:01 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 15:54 ?        00:00:01 /usr/lib/systemd/systemd --switched-root --system --deserialize 30
root         720       1  0 15:54 ?        00:00:00 /usr/lib/systemd/systemd-journald
root         733       1  0 15:54 ?        00:00:00 /usr/lib/systemd/systemd-udevd
systemd+    1107       1  0 15:55 ?        00:00:00 /usr/lib/systemd/systemd-resolved
root        1111       1  0 15:55 ?        00:00:00 /usr/sbin/ModemManager
root        1112       1  0 15:55 ?        00:00:00 /usr/sbin/NetworkManager --no-daemon
root        1114       1  0 15:55 ?        00:00:00 /usr/sbin/alsactl -s -n 19 -c -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main rdaemon
root        1117       1  0 15:55 ?        00:00:00 /usr/libexec/bluetooth/bluetoothd
chrony      1130       1  0 15:55 ?        00:00:00 /usr/sbin/chronyd
root        1135       1  8 15:55 ?        00:00:32 /usr/sbin/rngd -f
root        1138       1  0 15:55 ?        00:00:00 /usr/sbin/rsyslogd -n
root        1139       1  0 15:55 ?        00:00:00 /usr/lib/systemd/systemd-homed
root        1141       1  0 15:55 ?        00:00:00 /usr/lib/systemd/systemd-logind
avahi       1148    1115  0 15:55 ?        00:00:00 avahi-daemon: chroot helper
dbus        1149       1  0 15:55 ?        00:00:00 /usr/bin/dbus-broker-launch --scope system --audit
dbus        1168    1149  0 15:55 ?        00:00:00 dbus-broker --log 4 --controller 9 --machine-id 7dda623a3a624e458a393c700c042270 --max-bytes 536870912 --max-fds 4096 --max-matches 131072 --audit
jdoe      1174       1  0 15:55 ?        00:00:00 /usr/lib/code-server/lib/node /usr/lib/code-server
root        1196       1  0 15:55 ?        00:00:00 /usr/sbin/gssproxy -D
root        1203       1  0 15:55 ?        00:00:00 /usr/sbin/atd -f
root        1204       1  0 15:55 ?        00:00:00 /usr/sbin/crond -n
root        1207       1  0 15:55 tty1     00:00:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
jdoe      1261    1174  0 15:55 ?        00:00:00 /usr/lib/code-server/lib/node /usr/lib/code-server
jdoe      1297    1261  0 15:55 ?        00:00:00 /usr/lib/code-server/lib/node /usr/lib/code-server/lib/vscode/out/vs/server/fork
root        1315       1  0 15:55 ?        00:00:00 /usr/lib/systemd/systemd-userdbd
root        1320       1  0 15:55 ?        00:00:00 /usr/lib/systemd/systemd --user
root        1321    1320  0 15:55 ?        00:00:00 (sd-pam)
root        1329    1320  0 15:55 ?        00:00:00 /usr/bin/python3 -u /usr/bin/autojack
root        1339    1320  0 15:55 ?        00:00:00 /usr/bin/dbus-broker-launch --scope user
root        1353    1339  0 15:55 ?        00:00:00 dbus-broker --log 4 --controller 10 --machine-id 7dda623a3a624e458a393c700c042270 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000
root        1379       1  0 15:55 ?        00:00:00 ssh-agent -s
root        1461    1459  0 15:56 ?        00:00:00 sshd: root@pts/0
root        1462    1461  0 15:56 pts/0    00:00:00 -bash
root        1519    1315  0 16:00 ?        00:00:00 systemd-userwork
root        1520    1315  0 16:00 ?        00:00:00 systemd-userwork
root        1521    1315  0 16:00 ?        00:00:00 systemd-userwork
root        1544    1462  0 16:01 pts/0    00:00:00 ps -ef
5
  • 1
    What happens if you don’t use “exec”? It might tell you what is happening. Most likely, systemctl is exiting immediately because that’s it’s job, to talk to the systemd process.
    – jsbillings
    Aug 24 at 23:29
  • @jsbillings I've been using exec for years, but your idea is still a good one to try in case something changed. Sadly, I just tried a simple systemctl suspend (without exec) and the same thing happens. Bummer. LoL
    – NYCeyes
    Aug 24 at 23:57
  • 2
    You shouldn't use code formatting for arbitrary words (suspend, resume, nvidia, driver, "lid is always closed", etc). They make the post harder to read. Thank you!
    – Jeff Schaller
    Aug 25 at 1:15
  • I've never heard anyone complain about this before (on here or S/O). As well, the words aren't arbitrary to me. Thank you!
    – NYCeyes
    Aug 25 at 1:57
  • 2
    For what its worth, I also find it strange. At best, it makes it confusing because I expect things formatted that way to be commands or filenames (or maybe output) and it's harder to understand when they're not. At worst, it feels like I'm reading a Zippy the Pinhead comic.
    – mattdm
    Aug 25 at 23:13
1

I think this is an issue with the 470 nvidia driver. I am experiencing the same problem under Fedora 34 with the driver from RPMFusion. Uninstalling the driver fixes the issue, but it's not really ideal. I tried downgrading to the 465 driver, but it left my laptop such that it wouldn't boot, even into single user mode. I gave up for now.

4
  • 1
    I think you may be onto something. I have the 470 version as well. Someone else complained here: forums.developer.nvidia.com/t/…
    – NYCeyes
    Aug 27 at 0:57
  • 1
    See here in /usr/lib/modprobe.d/nvidia-power-management.conf set NVreg_PreserveVideoMemoryAllocations to 0
    – Vic Ricker
    Aug 30 at 21:34
  • Did the above work for you? I tried it, but in /etc/modprobe.d/ and it didn't work for me, sadly. Can you share your entry? Thank you.
    – NYCeyes
    Sep 1 at 0:12
  • 1
    It worked until another update was released that broke it. There is a fix, however: sudo dnf install xorg-x11-drv-nvidia-power sudo systemctl enable nvidia-{suspend,resume,hibernate} # Optional: tweak "nvidia options NVreg_TemporaryFilePath=/var/tmp" from /etc/modprobe.d/nvidia.conf as needed if you have issue with /tmp as tmpfs with nvidia suspend ) That's documented on the rpmfusion nvidia page.
    – Vic Ricker
    Sep 3 at 1:56
0

I posted this issue to RPMfusion bugzilla here. They alerted me to the solution (posted a couple of days prior) here.

SOLUTION SUMMARY:

root# dnf -y install xorg-x11-drv-nvidia-power # The new package containing the below.
root# systemctl enable nvidia-suspend.service
root# systemctl enable nvidia-resume.service
root# systemctl enable nvidia-hibernate.service
root# reboot

Note: This answer summarizes the bug and solution, but I marked Vic's solution above as the answer since he documented the solution in his follow-on comments (and deserves credit).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.