This bug was fixed in the package gdm3 - 42.0-1ubuntu7.22.04.3 --------------- gdm3 (42.0-1ubuntu7.22.04.3) jammy; urgency=medium
* debian/patches/ubuntu/gitlab_clearing_signal.patch: - clear signal handlers after udev settle to avoid unexpected session logouts, thanks Ghadi Rahme (lp: #2020641) -- Sebastien Bacher <seb...@ubuntu.com> Thu, 01 Jun 2023 12:37:58 +0200 ** Changed in: gdm3 (Ubuntu Jammy) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gdm3 in Ubuntu. https://bugs.launchpad.net/bugs/2020641 Title: Installing or removing apps through snap-store launches another gdm session Status in gdm3 package in Ubuntu: Fix Released Status in gdm3 source package in Jammy: Fix Released Status in gdm3 source package in Kinetic: Won't Fix Status in gdm3 source package in Lunar: Fix Released Status in gdm3 source package in Mantic: Fix Released Bug description: gdm3 version: 42.0-1ubuntu7.22.04.2 Ubuntu version: Ubuntu 22.04.2 LTS [Description] Installing or removing snap packages through NICE DCV on AWS will cause the user to be kicked out of their session. The issue happens on machines running nvidia GPUs (passed through to a VM) with the GRID driver installed as well as the normal nvidia driver. [Steps to reproduce] Simply install or remove any snap through the snap store will trigger the issue, for example: $ snap install skype also running any of the following commands will also trigger the issue: $ snap connect skype:opengl :opengl $ snap disconnect skype:opengl :opengl $ snap connect skype:camera :camera $ snap disconnect skype:camera :camera After further investigation I was able to pin down the issue to udev and could reproduce the issue by running the following command: $ sudo udevadm trigger --parent-match=/sys/devices/pci0000:00/0000:00:1e.0/drm/card0 where "/sys/devices/pci0000:00/0000:00:1e.0/drm/card0" corresponds to the nvidia GPU of my instance. A more generic way of triggering the issue would be running: $ sudo udevadm trigger [Solution] I have investigated the issue and discovered that it lies within GDM3 in the "udev_is_settled" function (daemon/gdm-local-display-factory.c). In the case where the udev is settled the line "g_clear_signal_handler (&factory->uevent_handler_id, factory->gudev_client);" at the end of the function is triggered however this is not the case when the function returns early and will lead to the user being logged out. In its current implementation there are three different return points before "g_clear_signal_handler" is executed where the udev devices would already have settled. I have written a patch that fixes this issue by making sure the function "g_clear_signal_handler" is executed in all cases for which the udev is settled. [possible regressions] Excessive clearing of the signal handler might cause a case where it is not being re-initialized the next time it is needed. [Base test plan] This test plan is to make sure the issue listed in the description section is fixed. 1. Create a new nvidia accelerated VM instance on AWS with NICE DCV and the GRID driver (or normal driver) installed. Make sure the GPU is being fully passed through to the instance (do not slice the GPU). 2. Access the instance using the NICE DCV client and login. 3. Install any snap package (E.g $ snap install skype). 4. Verify there are no new sessions being launched with the user being gdm. $ sudo loginctl Also make sure that you don't get logged out of your own session. 5. Repeat step 4 while running the following command as well: $ sudo udevadm trigger 6. If the current session stays active and no new sessions spawn while performing step 3 or 5, the test succeeded. [Extra tests] This test plan is a sanity check to make sure no regressions have been created. 1. Login to the session 2. Run a few applications (E.g: Nautilus, gedit, terminal, firefox, skype, libreoffice, mpv, vlc...) and use some on the built in features (E.g: the launcher, search...) 3. Switch sessions without terminating the current one. 4. Login as a separate user and repeat step 2 5. Go back to the first session and make sure everything behaves as expected 6. Switch to init 3: $ init 3 and go back to init 5 afterwards: $ init 5 7. If no issues were found, the test succeeded. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/2020641/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp