udevadm: trigger --type=failed deprecation
Hi all,
So, Udev-173 added a log message warning us that 'udevadm trigger --typeúiled' is deprecated, which over in LFS we use in a 'udev_retry' bootscript in an attempt to retry failed events, for example those caused by slow device initialization.
The ChangeLog fails to mention a preferred alternative mechanism for performing such event retries, or are such things not needed due to changes in the kernel?
Any advice you can give would be appreciated.
Thanks,
Matt.
Quoted 4 lines · Matthew Burgess
So, Udev-173 added a log message warning us that 'udevadm trigger --typeúiled' is deprecated, which over in LFS we use in a '
udev_retry' bootscript in an attempt to retry failed events, for example those caused by slow device initialization.
What is a 'slow' device? RUN+= needs to be explicitly marked to 'fail'
events. What kind of rules do you exactly have there that tells RUN+to mark it as failed if needed?
Quoted 5 lines
The ChangeLog fails to mention a preferred alternative mechanism for performing such event retries, or are such things not needed due to changes in the kernel?
Any advice you can give would be appreciated.
Depends on what you need:
Real services subscribe to events and do device enumeration at startup. They never really need hacks like 'failed' events.
Half-proper services trigger 'change' events when they are started up to find all devices which are already there. This is a hack and not recommended to use, but still better than hooking RUN+= stuff in, and relying on --typeúiled.
There is no real point in time, where an init script should try once again, just to see if has more luck than the on first run. Stuff that needs things like that usually needs to be fixed to better integrate with early boot, and it should no rely on udev to help papering over such issues, and just blindly run all these events again.
If services still want that, they can implement this logic on their own, the udev runtime directory is always writable.
Kay
Quoted 7 lines · Matthew Burgess
Quoted 1 line · Kay Sievers
On Wed, Aug 3, 2011 at 00:01, Matthew Burgess <[email protected]> wrote:
# This causes the system clock to be set as soon as
/dev/rtcbecomes available. SUBSYSTEM="rtc", ACTION="add", MODE="0644", RUN+="/etc/rc.d/init.d/setclock start" KERNEL="rtc", ACTION="add", MODE="0644", RUN+="/etc/rc.d/init.d/setclock start"
Quoted 7 lines
I have a suspicion that the rtc rule could fail if a user had /var as a separate partition, and
/dev/rtcwas created before the /var partition had been mounted (the setclock script calls out to hwclock, which requires/var/lib/hwclock/adjtime). Our initscripts in question are S10udev and S40mountfs, so I guess this is theoretically possible.Do you agree with the above analysis, and if so what do I need to do to fix this?
That's all fragile. My take is that userspace should not fiddle with the rtc clock at all. The kernel itself syncs properly with the rtc, long before userspace even runs, which is the only sensible thing to do, you don't want random jumps in system time. Userspace has no idea what the correct time is until ntp runs anyway.
There is only one 'broken' setup that needs some adjusting, and that is rtc in localtime. That should ideally be fixed by configuring Windows to run the rtc in UTC, which works totally fine these days If you really want to support that localtime crap, just adjust the timezone in the kernel, but don't fiddle with broken adjtime, hwclock or anything else. If anyone wants proper time, he needs ntp, not some wild guessing by tools, that have no idea what the actual time really is. What distros did here in the past is not convincing at all.
This is what systemd does:
http://cgit.freedesktop.org/systemd/commit/?idy48c4dfbea73ac21250b588089039aa17a90386
http://cgit.freedesktop.org/systemd/commit/?idÚ2617378523e007ec0c6efe99d0cebb2be994e1
and it will never touch the clock but supports rtc in localtime.
Running adjtime or hwclock and rtc in localtime will break all sorts of setups like live-cds, and so on.
Quoted 8 lines
I could just remove the RUN+= from the rtc rule, and have setclock be an initscript that starts after S40mountfs. Â I think we used to have things configured this way, but moved to the RUN+= method a while ago.
Aside from that issue, is there a way to ask udev to print all failed events, as opposed to retrying them. Â As LFS is a fairly minimal system, I'm concerned that users may end up creating or installing bootscripts that have similar issues, so having a way of printing failed events would be a useful first step in diagnosing their issues.
No, the entire tracking of failed events will be removed. And no events are marked as to-be-tracked by default, so there is nothing to print usually.
If you have marked events, you can run 'trigger --typeúiled -n -v' and it will print what it would do. But it is not used today for anything useful, and don't rely on that in the future, it will go away.
Kay