You are not logged in.

#1 2015-04-13 05:32:29

tom.ty89
Member
Registered: 2012-11-15
Posts: 897

About purpose of udevadm settle (in udev initcpio hook)

Does anyone know the purpose `udevadm settle`? I checked systemd-udev-trigger.service, it consists of the other two lines in the hook but not this one. Is there a reason that it's put in the hook?

I notice that it make something weird happen with this command in the hook:

First it shows something like /dev/sda2 instead of the UUID during boot even if I use UUID in the "root=" kernel param. Without the command it shows the UUID. Though this doesn't seem to harm, just weird.

But it could also prevent a udev rule from loading in a weird way, for example if I have the following:

ATTR{devpath}=="13", ATTR{power/wakeup}="enabled"
ATTR{devpath}=="14", ATTR{power/wakeup}="disabled"

Only the "enabled" line gets applied for certain but not (and only not) the "disabled" line if `udevadm settle` is in the hook. The "disabled" line can only get applied randomly. Without the settle command everything works as expected and consistently.

I made quite certain that it has nothing to do with the rules themselves (styles or conflicts). And the rules get applied as expected if I run `udevadm trigger` after boot. It's like the trigger command(s) was "cut off" at random point by the settle command.

Last edited by tom.ty89 (2015-04-13 05:34:16)

Offline

#2 2015-04-13 07:40:40

tom.ty89
Member
Registered: 2012-11-15
Posts: 897

Re: About purpose of udevadm settle (in udev initcpio hook)

I think I found out the rationale myself. Basically `udevadm settle` in the udev hook aims to provide a timeout (2min by default) for the triggered events, yet:
http://cgit.freedesktop.org/systemd/sys … 684d225787
because of this regression (which was only fixed two days ago), the purpose of the command is distorted (which exits immediately)

I'm going to build systemd from git to confirm and see if whether it's also the reason for the UUID not being shown.

Offline

#3 2015-04-13 08:49:28

tom.ty89
Member
Registered: 2012-11-15
Posts: 897

Re: About purpose of udevadm settle (in udev initcpio hook)

After testing systemd-git and a second thought I think my theory wasn't correct.

If the aim is to provide a timeout for the triggered events, and the bug makes the timeout become 0, at most the command would be a no-op. But the fact is it seems to affect/changed the queued events in some way, which I'm not sure if it's supposed to do so. (Another upstream bug?)

Also is the 2 min timeout necessary for the hook anyway?

Last edited by tom.ty89 (2015-04-13 08:50:10)

Offline

#4 2015-04-13 13:46:06

tom.ty89
Member
Registered: 2012-11-15
Posts: 897

Re: About purpose of udevadm settle (in udev initcpio hook)

I am even more confused after trying the systemd hook. When the hook is used instead of the udev hook, the rule has problem of being load again while no `udevadm settle` is run (systemd-udev-settle.service is not included in the initramfs and doesn't seem to have got run afterwards (systemctl status))

Offline

#5 2015-04-13 14:12:49

tom.ty89
Member
Registered: 2012-11-15
Posts: 897

Re: About purpose of udevadm settle (in udev initcpio hook)

Okay I try to add "sleep 1" to /lib/initcpio/hook/udev or /lib/systemd/system/systemd-udev-trigger.services after `udevadm trigger --action=add --type=devices`, seems to make it consistent both way.
So could it be a defect of `udevadm trigger`?

P.S. I think the reason that it would work when I remove `udevadm settle` in the hook is somehow it adds a bit of extra time during the boot process (after the trigger command)

Last edited by tom.ty89 (2015-04-13 14:14:32)

Offline

#6 2015-04-13 15:16:19

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,739

Re: About purpose of udevadm settle (in udev initcpio hook)

The best explanation I was able to find was on Stack Overflow. 
As a matter of style on the Arch Forums, if no one has responded to your posts, consider using the edit function instead of posting new threads.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#7 2015-04-13 16:05:31

teateawhy
Member
From: GER
Registered: 2012-03-05
Posts: 1,138
Website

Re: About purpose of udevadm settle (in udev initcpio hook)

tom.ty89 wrote:

After testing systemd-git and a second thought I think my theory wasn't correct.

If the aim is to provide a timeout for the triggered events, and the bug makes the timeout become 0, at most the command would be a no-op. But the fact is it seems to affect/changed the queued events in some way, which I'm not sure if it's supposed to do so. (Another upstream bug?)

The man page doesn't say that the order of events is changed by udevadm settle, so either the software, or the man page is wrong. I guess you should make a bug report about this.

Also is the 2 min timeout necessary for the hook anyway?

There are two timeouts, one performed by systemd via TimeoutSec=180, and one performed by udevadm settle whose default timeout is 180 seconds as well. I suspect that this is somewhat duplicating functionality, but i'm not sure if the functionality is completely the same. I guess that the systemd TimeoutSec can be removed because udevadm will stop after 180 seconds anyway.

Offline

#8 2015-04-13 16:25:31

tom.ty89
Member
Registered: 2012-11-15
Posts: 897

Re: About purpose of udevadm settle (in udev initcpio hook)

I filed a bug report: https://bugs.archlinux.org/task/44572

I suspect it's a `udevadm control --exit` problem, although I'm not sure if it is supposed to wait until everything is done. But despite the default timeout and what I set, it exit with a status of 0, while leaving my rule unapplied.

Also anyone know how does it exit in the initramfs environment if the systemd hook is used instead?

P.S. Sorry for the bumps

Last edited by tom.ty89 (2015-04-13 16:28:54)

Offline

Board footer

Powered by FluxBB