Bug 844556

Summary: multi-seat udev rules not fully set up prior to multiuser.target
Product: [Fedora] Fedora Reporter: Ravikiran Rajagopal <ravi>
Component: systemdAssignee: systemd-maint
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: johannbg, lnykryn, lpoetter, metherid, msekleta, notting, plautrba, systemd-maint, vpavlin
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-11 13:30:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ravikiran Rajagopal 2012-07-31 04:55:22 UTC
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 23:50:06 UTC
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 04:26:33 UTC
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 04:31:35 UTC
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 13:49:19 UTC
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 13:51:30 UTC
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 13:30:52 UTC
Closing due to lack of response.

Comment 7 Ravikiran Rajagopal 2013-01-12 19:05:53 UTC
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.