Ubuntu Version:
Example: 22.04 LTS
Desktop Environment (if applicable):
KDE Plasma
Problem Description:
Every time it goes to sleep, the screen does not turn back on and I have to hard reset
Example:
Relevant System Information:
Screenshots or Error Messages:
N/A
What I’ve Tried:
I tried editing the grub menu per this suggestion. It didn’t do anything to help the issue
Before Posting:
Not that I could see
I’ve seen this behavior on Ubuntu Studio + NVidia, both 22.04 LTS and 24.04 LTS.
For me the solution is to add the line
exit 0
as the first non-comment line in the file /usr/bin/nvidia-sleep.sh
If your system has this file as the result of installing the NVidia proprietary driver, perhaps this hack can fix it for you as well. I don’t see any “side effects” of using this approach, which I’ve done for at least a year now.
EDIT: for information, I’m running the 535.288.01 release of the NVidia proprietary driver. I briefly tested the 585 version, and it had almost the opposite issue for me - my system would sleep for a second or two then immediately wake up. The command
sudo ubuntu-drivers devices
still recommends the 535 driver for my old NVidia hardware.
This is what is currently in that file:
So, to be clear, the goal is just to bypass the suspend state altogether?
Yes, exactly. Mine has “exit 0” right where your cursor is.
EDIT: OK, thinking about it, the goal is to bypass the execution of this script. I don’t know exactly what it does other than to say it messes with the virtual terminals. My systems sleeps and wakes up completely normally with this hack.
Well, you’re right. That did it! Thank you.
Incidentally, if you’ve figured out HDMI issues with your NVIDIA card, maybe you can help me with my other problem.
Tapped out on that one, sorry. I’m using the two DVI connections with my ancient and much beloved 1920x1200 Lenovo monitors.
Gotcha. Thanks for all your help on this!
You’re welcome, very glad it worked for you.
Something to bear in mind, for the record: you’ll need to repeat that modification when major updates to the NVidia driver are installed. For example going from 535.aaa.bb to 580.ccc.dd. Minor updates like 535.aaa.bb to 535.xxx.yy don’t seem to touch that file and therefore don’t trigger the manual modification to /usr/bin/nvidia-sleep.sh.
One shouldn’t need to manipulate files in /usr/bin directly, if it can be helped at all. As you have found out, those files are owned by the NVIDIA driver packages and will be overwritten, when they get upgraded.
A better solution is to find the systemd service unit, which invokes that script and override the ExecStart= command line to use the executable without absolute patch:
[Service]
ExecStart=
ExecStart=nvidia-sleep.sh
That way on can put the edited version in /usr/local/bin, which is in the standard $PATH of systemd units and has higher priority, because it comes first in the list. That location is there for precisely this kind of stuff, and the package manager won’t touch it.
Alternatively, you can use diversions, but I think those should be considered a matter of last resort, when no other way can be found, which is virtually never.
As to what that script does — not an NVIDIA user, so I can only go by what’s written there: it switches to the VT (virtual terminal), in which the X.org server is running; presumably that’s a hack to work around one of the plentiful issues surrounding NVIDIA drivers. It shouldn’t be required anymore, given that Ubuntu 26.04 is now using Wayland.
But it suggests that, on resume, you should be able to just switch to the correct VT, in which the Wayland desktop runs, by pressing CtrlAltF1; could be CtrlAltF2.
That is really excellent education, @peterwhite23 , thanks very much for taking the time to respond. I’m always eager to learn “the right way” to do things.
Erm, I’ve just realized that simply disabling said systemd service unit, if it exits, should do. So I installed the package to be able to grep in its contents and found that there is one caller that can’t be overridden as it seems: /usr/lib/systemd/system-sleep/nvidia; there is no override mechanism for that, at least none that I know of. It looks like dpkg-divert it is then. 
sudo dpkg-divert --local --no-rename /usr/bin/nvidia-sleep.sh
That should do it. From now on package upgrades will divert that file to /usr/bin/nvidia-sleep.sh.distrib and not clobber your local edit. Since that script will exit 0 right away, you could even do this:
cd /usr/bin && sudo ln -sf true nvidia-sleep.sh
Shave off some CPU cycles by not having to spawn a shell which immediately exits. 
That will destroy the file, however, so, if you intend to keep the original, change the the above command to:
sudo dpkg-divert --local --rename /usr/bin/nvidia-sleep.sh
That way you will have a backup of the packaged version. But then you have to create the symbolic link, because callers of that script will get a no such file error.
On a more ranty note, I’m underwhelmed by the quality of the package contents, because this happened during installation:
Created symlink /etc/systemd/system/systemd-hibernate.service.wants/nvidia-hibernate.service → /usr/lib/systemd/system/nvidia-hibernate.service.
Created symlink /etc/systemd/system/systemd-suspend.service.wants/nvidia-resume.service → /usr/lib/systemd/system/nvidia-resume.service.
Created symlink /etc/systemd/system/systemd-hibernate.service.wants/nvidia-resume.service → /usr/lib/systemd/system/nvidia-resume.service.
Created symlink /etc/systemd/system/systemd-suspend-then-hibernate.service.wants/nvidia-resume.service → /usr/lib/systemd/system/nvidia-resume.service.
Created symlink /etc/systemd/system/systemd-suspend.service.wants/nvidia-suspend.service → /usr/lib/systemd/system/nvidia-suspend.service.
There are three WantedBy= directives in nvidia-resume, for instance:
# /usr/lib/systemd/system/nvidia-resume.service
[Install]
WantedBy=systemd-suspend.service
WantedBy=systemd-hibernate.service
WantedBy=systemd-suspend-then-hibernate.service
The proper way of running services at suspend/hibernate/resume is to just have the sleep.target special target depend on them, so this is equivalent and less ugly:
# /etc/systemd/system/nvidia-resume.service.d/override.conf
[Unit]
After=sleep.target
[Install]
WantedBy=
WantedBy=sleep.target
(that’s a working override, BTW, can put it in the location in the comment and then run systemctl reenable nvidia-resume after the obligatory systemctl daemon-reload)
I can only hope that Canonical is just repackaging NVIDIA’s slop here, because that’s a look under the hood I’d rather not have taken. 
Plus, these services make /usr/lib/systemd/system-sleep/nvidia utterly redundant! This is what the official systemd docs say:
Note that scripts or binaries dropped in
/usr/lib/systemd/system-sleep/are intended for local use only and should be considered hacks.
Very interesting and thanks again, @peterwhite23 . A fair bit beyond my experience and willingness to tinker, though. I have learned the hard lesson - several times, and going way back to the proprietary fglrx drivers from AMD - that a video driver that works at all is something to not be trifled with. Once you have something that works and does what you need it to do, daily burnt offerings to the Linux gods are appropriate.
But dpkg-divert isn’t all that scary. It is just a way for users/admins to prevent their local changes from being overwritten on every single upgrade of said package. If something does go wrong, e.g. because some major change actually required nvidia-sleep.sh to really run its intended course, without short-circuiting it to exit 0, you can simply link the official package version:
cd /usr/bin
sudo mv nvidia-sleep.sh{,.bak}
sudo ln -s nvidia-sleep.sh{.distrib,}
I probably should have made that more clear in previous post. 
Yes, those are the trials and tribulations of using proprietary drivers. 
I have to say, though, that I haven’t had any issues like that, ever since I decided to never use an NVIDIA GPU again, unless they get their act together an provide actual FOSS drivers. This laptop has a Ryzen 5 3500U and the iGPU is enough for my purposes; no proprietary driver required, just the vanilla Ubuntu kernel and Mesa. Besides some rather minor teething problems with Ubuntu 19.10, when this unit was brand new, it’s been plain sailing ever since. Maybe take that under advisement for your next hardware purchase; no need for superstitious rituals. 
This topic was automatically closed 18 hours after the last reply. New replies are no longer allowed.