FS#36588 - [systemd] systemd-udev-settle.service seems to be broken (systemd in initramfs)

Attached to Project: Arch Linux
Opened by Christopher Reimer (CReimer) - Sunday, 18 August 2013, 19:12 GMT
Last edited by Dave Reisner (falconindy) - Monday, 19 August 2013, 15:20 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To No-one
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
systemd-udev-settle.service exits far too early and services which rely on a fully booted system are crashing


Additional info:
* systemd 206-2
* systemd hook in mkinitcpio.conf
* systemd-analyze plot attached

Please take a closer look at the end of the plot, especially dev-ttyUSB0.device
oscam.service is the service file which should start after dev-ttyUSB0.device.
   plot.svg (74.4 KiB)
This task depends upon

Closed by  Dave Reisner (falconindy)
Monday, 19 August 2013, 15:20 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Though, more like "can't fix". These services need to adapt to the hotplug model of linux.
Comment by Dave Reisner (falconindy) - Monday, 19 August 2013, 01:53 GMT
Why do you need udev-settle to begin with? What is a "fully booted system" and why can't your services depend on devices rather than system states which can't be well defined?

In general, udevadm settle is doing what it's "designed" to do. There's no guarantees that events which settle waits on don't generate further events; e.g. enumerating the ports on a USB hub can and will generate further events which settle doesn't wait on because it doesn't know about them.

I can tell you that upstream won't be interested in "fixing" the behavior of settle.
Comment by Christopher Reimer (CReimer) - Monday, 19 August 2013, 08:35 GMT
Yes, with "fully booted systemd" I mean the point in the boot process in which all connected devices are fully initialised.

I'm maintainer of vdr4arch. A small project which provides vdr packages(tvdr.de) for Arch Linux.
There are two daemons (oscam and vdr) which expect to be started after all devices, they want to use, are fully initialised.

oscam waits for several serial smartcard readers.
vdr waits for DVB devices.

I can't hardcode this, becaus this would only fit my system. On other systems there may be more or less cardreaders/DVB cards.
Comment by Dave Reisner (falconindy) - Monday, 19 August 2013, 11:09 GMT
Sorry but this setup simply cannot work for the reasons I've already stated. Your services need to learn how to cope with hardware coming and going. Depending on settle is a hack.

Loading...