[systemd-devel] Starting Display Managers
Hello. Several days ago I stumbled upon an interesting race condition (which is not a bug in systemd) that I want to share now. To reproduce: install lxdm, and the following (buggy) unit to start lxdm on boot: [Unit] Description=LXDE Display Manager [Service] ExecStart=/usr/sbin/lxdm # After each successful logout, lxdm terminates Restart=on-success [Install] WantedBy=graphical.target Note that, as compared to the Arch Linux unit, this misses the dependency on systemd-user-sessions.service, but in fact the race condition is deeper. The problem is that lxdm starts the X server, and it has certain /dev requirements that vary with hardware and, at least from my first impression, not known in advance. If the user has a graphics card supported by open-source DRI-based drivers with mandatory KMS, then /dev/dri/card0 (or maybe card1 in dual-gfx setups) is needed. And for Radeon TURKS cards, this only appears after loading firmware (which takes some time). If this is a tablet using the fbdev driver, then /dev/fb0 is needed. And with yet-unsupported graphics cards, the vesa driver only needs /dev/mem or something like that which is always present given a devtmpfs. The question is: how does one write this dependency information, so that lxdm is not attempted to be started before udev creates the necessary device node? Yes, I understand that GPU hotplug in Xorg is the real answer, but we don't have that now, and I don't know how it would cover vesa-based screens. This is not exactly a theoretical question. While I could not reproduce this race using a RAID0 setup made from two Samsung SATA-III SSDs, it does trigger reliably (even with an Intel card) if one puts the entire system into an initramfs and makes the /init - usr/bin/systemd symlink. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting Display Managers
On Tue, Aug 21, 2012 at 11:09:10AM +0600, Alexander E. Patrakov wrote: If the user has a graphics card supported by open-source DRI-based drivers with mandatory KMS, then /dev/dri/card0 (or maybe card1 in dual-gfx setups) is needed. And for Radeon TURKS cards, this only appears after loading firmware (which takes some time). If this is a tablet using the fbdev driver, then /dev/fb0 is needed. And with yet-unsupported graphics cards, the vesa driver only needs /dev/mem or something like that which is always present given a devtmpfs. The question is: how does one write this dependency information, so that lxdm is not attempted to be started before udev creates the necessary device node? Yes, I understand that GPU hotplug in Xorg is the real answer, but we don't have that now, and I don't know how it would cover vesa-based screens. This bug prompted adding CanGraphical property to seat. See http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers lxdm should watch for seat property to change to CanGraphical=yes and then continue initialisation. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting Display Managers
On Tue, 21.08.12 11:09, Alexander E. Patrakov (patra...@gmail.com) wrote: The question is: how does one write this dependency information, so that lxdm is not attempted to be started before udev creates the necessary device node? Yes, I understand that GPU hotplug in Xorg is the real answer, but we don't have that now, and I don't know how it would cover vesa-based screens. Actually I do not think that Xorg GPU hotplug is the right answer here. Instead the display manager should probably not start any X server on a seat that is not graphical. For that it should watch the CanGraphical property of the seat (as Tomasz already mentioned). A temporary work-around could be to settle the video drivers using udevadm. (and only the video drivers please!), and add that to ExecStartPre= or so. This is not exactly a theoretical question. While I could not reproduce this race using a RAID0 setup made from two Samsung SATA-III SSDs, it does trigger reliably (even with an Intel card) if one puts the entire system into an initramfs and makes the /init - usr/bin/systemd symlink. Yes, this race is real, and right now no display manager really handles this correctly. Now that our boot times are so fast these kinds of races suddenly appear there never had been visible before. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
