udevadm: trigger --type=failed deprecation

udevadm: trigger --type=failed deprecation

[Matthew Burgess]

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.

Re: udevadm: trigger --type=failed deprecation

[Kay Sievers]

On Wed, Aug 3, 2011 at 00:01, Matthew Burgess
<matthew@linuxfromscratch.org> wrote:
> 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?

> 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

Re: udevadm: trigger --type=failed deprecation

[Kay Sievers]

On Wed, Aug 3, 2011 at 11:09, Matthew Burgess
<matthew@linuxfromscratch.org> wrote:
> On Wed, 3 Aug 2011 01:38:45 +0200, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Wed, Aug 3, 2011 at 00:01, Matthew Burgess <matthew@linuxfromscratch.org> wrote:

> # This causes the system clock to be set as soon as /dev/rtc becomes 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"

> I have a suspicion that the rtc rule could fail if a user had /var as a separate
> partition, and /dev/rtc was 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.

> 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

Re: udevadm: trigger --type=failed deprecation

[Matthew Burgess]

On Wed, 3 Aug 2011 01:38:45 +0200, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Aug 3, 2011 at 00:01, Matthew Burgess
> <matthew@linuxfromscratch.org> wrote:
>> 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?

Good question.  We try to stick as closely as possible to upstream's rules.

We only create 2 rules files in addition to those installed by your releases
which are:

--- Begin 55-lfs.rules ---

# /etc/udev/rules.d/55-lfs.rules: Rule definitions for LFS.

# Core kernel devices

# This causes the system clock to be set as soon as /dev/rtc becomes 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"

# Comms devices

KERNEL="ippp[0-9]*",       GROUP="dialout"
KERNEL="isdn[0-9]*",       GROUP="dialout"
KERNEL="isdnctrl[0-9]*",   GROUP="dialout"
KERNEL="dcbri[0-9]*",      GROUP="dialout"

--- End 55-lfs.rules ---

and 70-persistent-net.rules which is generated by following the instructions
at http://www.linuxfromscratch.org/lfs/view/development/chapter07/network.html.

I have a suspicion that the rtc rule could fail if a user had /var as a separate
partition, and /dev/rtc was 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?

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.

Thanks,

Matt.