On second thoughts, patching lunar is unlikely to be useful. So long as
the fix is in mantic for future releases, that's enough.
** Tags removed: verification-done-lunar
** Tags added: verification-needed-lunar
** Changed in: gdm3 (Ubuntu Lunar)
Status: Fix Committed => Won't Fix
** Changed in: gdm3 (Ubuntu Lunar)
Importance: High => Low
** Changed in: gdm3 (Ubuntu Kinetic)
Importance: Undecided => Low
--
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 Committed
Status in gdm3 source package in Kinetic:
Won't Fix
Status in gdm3 source package in Lunar:
Won't Fix
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 : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
