Bug 1577498 - systemd-logind restart code is broken somewhere (I'm not sure if it's fixed upstream yet or not)
Summary: systemd-logind restart code is broken somewhere (I'm not sure if it's fixed u...
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 28
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-05-12 13:19 UTC by Alan Jenkins
Modified: 2018-05-12 18:51 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-05-12 18:51:14 UTC
Type: Bug

Attachments (Terms of Use)

Description Alan Jenkins 2018-05-12 13:19:38 UTC
Description of problem:
SELinux enforcement is blocking the systemd code which would handle logind restart.

This is not urgent in itself, because no-one relies on the logind restart code.

Version-Release number of selected component (if applicable): 

How reproducible: as below

Steps to Reproduce:
1. Fedora Workstation 28
2. Boot
3. Log in to GNOME
4. In a terminal, run

   sudo lsof -p 1 | grep dri

Actual results:

/dev/dri/card0 is shown as being open in PID 1.  This is a copy of the FD which logind has granted to gnome-shell.  logind must keep this *exact* FD, in order that logind can force switches between sessions / VTs even when a session becomes non-responsive.  

But there is only *one* such FD shown...

Expected results:

In fact, there should be two such FDs shown.  Logging in to GNOME on Fedora, leaves gdm running on tty1, while gnome-shell runs on tty2.

Additional info:

This appears to be a regression from Fedora 27.

Additionally, the "expected results" can be obtained by booting with `enforcing=0`.  However nothing appears in "Selinux Troubleshooter", and there seems to be nothing relevant in the audit log.  So it is a "dontaudit" rule or something more subtle.


Context: I am having some unexpected behaviour with memory/swap usage.  I seem to be  filling up memory quite quickly, just from starting a single VM.  I have 8GB RAM, and the VM is allocated 1.75GB.  I found this strange behaviour with the DRI FDs because I started investigating whether my memory usage problem was  related to the Fedora 27 bug described here:


Comment 1 Alan Jenkins 2018-05-12 13:30:50 UTC
Sorry, I wasn't clear.  logind needs to keep these FDs, and it's supposed to keep them even if it's restarted.  The ways this feature works is that when the FD is created, it is also sent to systemd for safe-keeping.  (See `man sd_pid_notify_with_fds`.  This is also referred to as FDSTORE).

Looking at the `lsof` results it looks as if the initial FD passing to PID 1 works ok, but then when we switch sessions, the FD gets dropped for some reason.

You can see this, in that if you subsequently press ctrl+alt+f6 and log in on the text console, then running the `lsof` command will show that PID 1 has *no* open FDs for /dev/dri/card0.

Comment 2 Alan Jenkins 2018-05-12 13:37:17 UTC
Note if you then switch back to GNOME on tty2, the FD does not re-appear in PID 1.  PID 1 is left with zero FDs of /dev/dri/card0.

Comment 3 Alan Jenkins 2018-05-12 18:51:14 UTC
Gah. This is not a SELinux bug. I am having the same sort of problem on my laptop both with and without `enforcing=0`.

Partly it is awkward to reproduce, because of a systemd bug where unplugging an input device (e.g. mouse) causes logind to remove *all* the device FDs from PID 1.  So don't unplug your mouse from your laptop while testing this...

But more importantly, you have to watch out for the same side-issue on VMs, because they hotplug some magic tablet/touchscreen device at weird times. I think on VT switch, for example.  I think the way to test this on a VM without such interference, is to run `systemctl mask spice-vdagentd.serivce` (and reboot) inside the VM.

The side-issue is fixed in the next release of systemd (v239). https://github.com/systemd/systemd/issues/8344

Then I'm still getting a different result between VM and the laptop itself.  On the laptop, after logging in to GNOME, PID 1 has one FDs of /dev/dri/card0.  Inside the F28 VM, after logging in to GNOME, PID 1 has zero FDs of /dev/dri/card0.

Only if I go back to the F27 VM, can I see the desired result of two FDs of /dev/dri/card0 in PID 1.

Note You need to log in before you can comment on or make changes to this bug.