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
NYCeyes
  • 229
  • 1
  • 3
  • 9
  • 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 '21 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 '21 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 '21 at 01: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 '21 at 01: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 '21 at 23:13

2 Answers2

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.

Vic Ricker
  • 26
  • 1
  • 1
    I think you may be onto something. I have the `470` version as well. Someone else complained here: https://forums.developer.nvidia.com/t/xorg-x11-drv-nvidia-470-63-01-1-fc33-src-rpm-crashes-when-systemctl-suspend-gtx1650/187566 – NYCeyes Aug 27 '21 at 00:57
  • 1
    [See here](https://bugzilla.rpmfusion.org/show_bug.cgi?id=6066) in /usr/lib/modprobe.d/nvidia-power-management.conf set NVreg_PreserveVideoMemoryAllocations to 0 – Vic Ricker Aug 30 '21 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 01 '21 at 00: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 03 '21 at 01: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).

NYCeyes
  • 229
  • 1
  • 3
  • 9