Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false
On Sun, 9 Jun 2024 at 21:07, Andreas Beckmann wrote: > > Hi Peter, > > thanks for testing that. > > On 08/06/2024 16.42, Peter De Wachter wrote: > > Those locations work. But the correct environment variable turns out to be > > SYSTEMD_SLEEP_FREEZE_USER_SESSIONS (plural), the NEWS file has it wrong. > > Hi Luca, > > do you need a cloned bug against systemd for the variable mismatch? Thanks but no need, it's just the changelog, already fixed it. > > (I've no idea why suspend seemed to work for me yesterday with the wrong > > variable. Today it definitely didn't.) The overrides probably also need to > > be installed for the other service files that run systemd-sleep: > > systemd-hybrid-sleep.service, systemd-hibernate.service and > > systemd-suspend-then-hibernate.service. > > Can you give some hints here? > > And if it is the case that we need these override variables in many > places, isn't there an easier way to "configure systemd-sleep behavior" > regardless of the way it is being called? This is a workaround, so the drop-in is the only way. The correct fix is for the functionality to stop relying on the user session being runnable to come out of suspension, as that's the real problem. I realize you can't fix this, but at least it should be reported upstream, asking them to fix it (they probably won't, I know)
Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false
Hi Peter, thanks for testing that. On 08/06/2024 16.42, Peter De Wachter wrote: Those locations work. But the correct environment variable turns out to be SYSTEMD_SLEEP_FREEZE_USER_SESSIONS (plural), the NEWS file has it wrong. Hi Luca, do you need a cloned bug against systemd for the variable mismatch? (I've no idea why suspend seemed to work for me yesterday with the wrong variable. Today it definitely didn't.) The overrides probably also need to be installed for the other service files that run systemd-sleep: systemd-hybrid-sleep.service, systemd-hibernate.service and systemd-suspend-then-hibernate.service. Can you give some hints here? And if it is the case that we need these override variables in many places, isn't there an easier way to "configure systemd-sleep behavior" regardless of the way it is being called? Andreas
Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false
Hi Andreas, Those locations work. But the correct environment variable turns out to be SYSTEMD_SLEEP_FREEZE_USER_SESSIONS (plural), the NEWS file has it wrong. (I've no idea why suspend seemed to work for me yesterday with the wrong variable. Today it definitely didn't.) The overrides probably also need to be installed for the other service files that run systemd-sleep: systemd-hybrid-sleep.service, systemd-hibernate.service and systemd-suspend-then-hibernate.service. On Fri, Jun 7, 2024 at 10:05 PM Luca Boccassi wrote: > On Fri, 7 Jun 2024 at 21:03, Andreas Beckmann wrote: > > > > On 07/06/2024 08.17, Peter De Wachter wrote: > > > systemd 256-rc3 was recently uploaded to Debian. Its NEWS file > mentions: > > > > > > * The behavior of systemd-sleep and systemd-homed has been > updated to > > >freeze user sessions when entering the various sleep modes > or when > > >locking a homed-managed home area. This is known to cause > issues with > > >the proprietary NVIDIA drivers. Packagers of the NVIDIA > proprietary > > >drivers may want to add drop-in configuration files that set > > >SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for > systemd-suspend.service > > >and related services, and > SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for > > >systemd-homed.service. > > > > Thanks for catching that. I'll try to include a fix with the upcoming > > uploads of the recent CVE series. > > > > As I'm not that familiar with configuring systemd bits, do you know what > > would be the correct locations and contents to ship the fix? > > > > If I read the documentation correctly, that should be > > > > /usr/lib/systemd/system/systemd-suspend.service.d/nvidia.conf > > = 8< = > > [Service] > > Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSION=false" > > = >8 = > > > > and > > > > /usr/lib/systemd/system/systemd-homed.service.d/nvidia.conf > > = 8< = > > [Service] > > Environment="SYSTEMD_HOME_LOCK_FREEZE_SESSION=false" > > = >8 = > > > > Could you verify that this works (after unapplying your temporary > solution)? > > Hi Andreas, I can confirm those are the correct locations. You can > also omit the quotes. >
Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false
On Fri, 7 Jun 2024 at 21:03, Andreas Beckmann wrote: > > On 07/06/2024 08.17, Peter De Wachter wrote: > > systemd 256-rc3 was recently uploaded to Debian. Its NEWS file mentions: > > > > * The behavior of systemd-sleep and systemd-homed has been updated > > to > >freeze user sessions when entering the various sleep modes or > > when > >locking a homed-managed home area. This is known to cause issues > > with > >the proprietary NVIDIA drivers. Packagers of the NVIDIA > > proprietary > >drivers may want to add drop-in configuration files that set > >SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for > > systemd-suspend.service > >and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false > > for > >systemd-homed.service. > > Thanks for catching that. I'll try to include a fix with the upcoming > uploads of the recent CVE series. > > As I'm not that familiar with configuring systemd bits, do you know what > would be the correct locations and contents to ship the fix? > > If I read the documentation correctly, that should be > > /usr/lib/systemd/system/systemd-suspend.service.d/nvidia.conf > = 8< = > [Service] > Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSION=false" > = >8 = > > and > > /usr/lib/systemd/system/systemd-homed.service.d/nvidia.conf > = 8< = > [Service] > Environment="SYSTEMD_HOME_LOCK_FREEZE_SESSION=false" > = >8 = > > Could you verify that this works (after unapplying your temporary solution)? Hi Andreas, I can confirm those are the correct locations. You can also omit the quotes.
Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false
On 07/06/2024 08.17, Peter De Wachter wrote: systemd 256-rc3 was recently uploaded to Debian. Its NEWS file mentions: * The behavior of systemd-sleep and systemd-homed has been updated to freeze user sessions when entering the various sleep modes or when locking a homed-managed home area. This is known to cause issues with the proprietary NVIDIA drivers. Packagers of the NVIDIA proprietary drivers may want to add drop-in configuration files that set SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for systemd-suspend.service and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for systemd-homed.service. Thanks for catching that. I'll try to include a fix with the upcoming uploads of the recent CVE series. As I'm not that familiar with configuring systemd bits, do you know what would be the correct locations and contents to ship the fix? If I read the documentation correctly, that should be /usr/lib/systemd/system/systemd-suspend.service.d/nvidia.conf = 8< = [Service] Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSION=false" = >8 = and /usr/lib/systemd/system/systemd-homed.service.d/nvidia.conf = 8< = [Service] Environment="SYSTEMD_HOME_LOCK_FREEZE_SESSION=false" = >8 = Could you verify that this works (after unapplying your temporary solution)? Thanks Andreas
Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false
Package: nvidia-driver Version: 545.23.06-1 Severity: normal systemd 256-rc3 was recently uploaded to Debian. Its NEWS file mentions: * The behavior of systemd-sleep and systemd-homed has been updated to freeze user sessions when entering the various sleep modes or when locking a homed-managed home area. This is known to cause issues with the proprietary NVIDIA drivers. Packagers of the NVIDIA proprietary drivers may want to add drop-in configuration files that set SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for systemd-suspend.service and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for systemd-homed.service. And indeed suspend would hang for me with either nvidia driver 545.23.06-1 or 535.161.08-2. For anybody stumbling on this bug report: The easiest way to do this by hand, is to run `systemctl edit systemd-suspend.service` and add the two lines: [Service] Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSION=false" -- Package-specific info: uname -a: Linux fractal 6.8.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.8.12-1 (2024-05-31) x86_64 GNU/Linux /proc/version: Linux version 6.8.12-amd64 (debian-ker...@lists.debian.org) (x86_64-linux-gnu-gcc-13 (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.8.12-1 (2024-05-31) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 545.23.06 Sun Oct 15 17:43:11 UTC 2023 GCC version: gcc version 13.2.0 (Debian 13.2.0-25) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ZOTAC International (MCO) Ltd. Device [19da:a454] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 Jun 7 07:45 /dev/dri/card0 crw-rw+ 1 root render 226, 128 Jun 7 07:45 /dev/dri/renderD128 crw-rw-rw- 1 root root 195, 254 Jun 7 07:45 /dev/nvidia-modeset crw-rw-rw- 1 root root 195, 0 Jun 7 07:45 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Jun 7 07:45 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Jun 7 07:45 pci-:01:00.0-card -> ../card0 lrwxrwxrwx 1 root root 13 Jun 7 07:45 pci-:01:00.0-render -> ../renderD128 video:x:44:pdewacht Alternative 'nvidia': nvidia - auto mode link best version is /usr/lib/nvidia/current link currently points to /usr/lib/nvidia/current link nvidia is /usr/lib/nvidia/nvidia slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu is /usr/lib/i386-linux-gnu/libEGL_nvidia.so.0 slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0 slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu is /usr/lib/i386-linux-gnu/libGLX_nvidia.so.0 slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1 slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy slave nvidia--nvidia-application-profiles-key-documentation is /usr/share/nvidia/nvidia-application-profiles-key-documentation slave nvidia--nvidia-blacklists-nouveau.conf is /etc/nvidia/nvidia-blacklists-nouveau.conf slave nvidia--nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh slave nvidia--nvidia-debugdump is /usr/bin/nvidia-debugdump slave nvidia--nvidia-drm-outputclass.conf is /etc/nvidia/nvidia-drm-outputclass.conf slave nvidia--nvidia-load.conf is /etc/nvidia/nvidia-load.conf slave nvidia--nvidia-modprobe.conf is /etc/nvidia/nvidia-modprobe.conf slave nvidia--nvidia-options.conf is /etc/modprobe.d/nvidia-options.conf slave nvidia--nvidia-settings is /usr/bin/nvidia-settings slave nvidia--nvidia-settings.1.gz is /usr/share/man/man1/nvidia-settings.1.gz slave nvidia--nvidia-settings.desktop is /usr/share/applications/nvidia-settings.desktop slave nvidia--nvidia-smi is /usr/bin/nvidia-smi slave nvidia--nvidia-smi.1.gz is /usr/share/man/man1/nvidia-smi.1.gz slave nvidia--nvidia_drv.so is /usr/lib/nvidia/nvidia_drv.so /usr/lib/nvidia/current - priority 545 slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/current/libEGL_nvidia.so.0 slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL_nvidia.so.0 slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu:
