Bug 844556 - multi-seat udev rules not fully set up prior to multiuser.target
multi-seat udev rules not fully set up prior to multiuser.target
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-31 00:55 EDT by Ravikiran Rajagopal
Modified: 2013-01-12 14:05 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-11 08:30:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ravikiran Rajagopal 2012-07-31 00:55:22 EDT
Description of problem:
Multi-seat rules are set up on a system with two video cards (both Radeon 6850). The rules are stored in /etc/udev/rules.d/72-seat2-config.rules for seat2. On boot up to graphical.target, the rules assigning hardware to seats are not always followed and fails about half the time. Logging into tty2, and running the following commands always fixes hardware assignments:
init 3
init 5

I don't think it matters but here are the contenets of 72-seat2-config.rules:

# XFX Radeon 6850 video and HDMI audio
TAG=="seat", ATTRS{vendor}=="0x1002", ATTRS{subsystem_vendor}=="0x1682", ENV{ID_SEAT}="seat2"
#TAG=="seat", ATTRS{vendor}=="0x1002", ATTRS{subsystem_vendor}=="0xaa08", ENV{ID_SEAT}="seat2"

# Keyboard (need to add PS2 port to this as well)
#TAG=="seat", ATTRS{name}=="CHESEN PS2 to USB Converter", ENV{ID_SEAT}="seat2"
TAG=="seat", ATTRS{name}=="AT Translated Set 2 keyboard", ENV{ID_SEAT}="seat2"

# Mouse
TAG=="seat", ATTRS{name}=="Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)", ENV{ID_SEAT}="seat2"

It seems that devices are not properly assigned to the appropriate seats prior to reaching graphical.target. Should graphical.target not depend on udev-settle.service?

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

systemd-44-17.fc17.i686
udev-182-3.fc17.x86_64

How reproducible:


Steps to Reproduce:
1. Set up multi-seat rules
2. Reboot
3. Check device assignment for each seat
  
Actual results:

Devices are mis-assigned half the time.

Expected results:

Devices are assigned to the correct seat

Additional info:

More details on my set up can be found at http://code.lexarcana.com/blog/ if needed.
Comment 1 Lennart Poettering 2012-08-08 19:50:06 EDT
udev-settle is kinda obsolete these days.

gdm should have no problems with seats that appear during runtime (rather then before gdm is started).

When this fails, does the property show up on the device if you check with "udevadm info -q /sys/..."?
Comment 2 Ravikiran Rajagopal 2012-08-14 00:26:33 EDT
I am not sure that gdm is the problem. For example, the following, saved as 
/etc/systemd/system/extra-wait.service and then enabled via systemctl, "fixes" 
the problem with 100% reliability:

===========

[Unit]
Description=Extra wait for udevadm to settle
After=basic.target udev-settle.service
Before=display-manager.service systemd-logind.service multi-user.target

[Service]
Type=oneshot   
RemainAfterExit=yes
ExecStart=/bin/sleep 60

[Install]
Requires=basic.target
RequiredBy=display-manager.service systemd-logind.service multi-user.target

===========

Without the workaround above, when it fails, I can see via udevadm that the 
devices have the correct properties (i.e., are assigned to the right seat). Is 
there any more information I can supply?
Comment 3 Ravikiran Rajagopal 2012-08-14 00:31:35 EDT
I am not sure that gdm is the problem. For example, the following, saved as 
/etc/systemd/system/extra-wait.service and then enabled via systemctl, "fixes" 
the problem with 100% reliability:

===========

[Unit]
Description=Extra wait for udevadm to settle
After=basic.target udev-settle.service
Before=display-manager.service systemd-logind.service multi-user.target

[Service]
Type=oneshot   
RemainAfterExit=yes
ExecStart=/bin/sleep 60

[Install]
Requires=basic.target
RequiredBy=display-manager.service systemd-logind.service multi-user.target

===========

Without the workaround above, when it fails, I can see via udevadm that the 
devices have the correct properties (i.e., are assigned to the right seat). Is 
there any more information I can supply?
Comment 4 Lennart Poettering 2012-09-14 09:49:19 EDT
The slep should normally not be necessary, as gdm should notice when seats become available and gain the graphical property.
Comment 5 Lennart Poettering 2012-09-14 09:51:30 EDT
How did you create the rules? Can you create these rules with "loginctl attach"?

Can you please paste the output of "udevadm info /dev/dri/card0" (and similar for the other card) once when it is incorrectly assigned, and once when it is correctly assigned?
Comment 6 Lennart Poettering 2013-01-11 08:30:52 EST
Closing due to lack of response.
Comment 7 Ravikiran Rajagopal 2013-01-12 14:05:53 EST
Apologies, I no longer have access to that machine (as the motherboard died). If the problem persists when I set up a new system, I will open a new bug report. Apologies.

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