[systemd-devel] [PATCH] udev: Restore udevadm settle timeout

[David Herrmann]

Hi

On Wed, May 6, 2015 at 4:31 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Mon, Apr 20, 2015 at 10:33:48AM +0200, David Herrmann wrote:
>> Hi
>>
>> On Sat, Apr 11, 2015 at 9:38 PM, Nir Soffer <nirsof at gmail.com> wrote:
>> > On Sat, Apr 11, 2015 at 1:36 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
>> >> > @@ -139,6 +142,9 @@ static int adm_settle(struct udev *udev, int argc, char *argv[]) {
>> >> >                          break;
>> >> >                  }
>> >> >
>> >> > +                if (now(CLOCK_MONOTONIC) >= deadline)
>> >> > +                        break;
>> >> > +
>> >>
>> >> Previous udevadm allowed timeout=0 to disable this. I added the condition.
>> >
>> > Hi David,
>> >
>> > I think the handling of timeout=0 is incorrect now. The manual says:
>> >
>> >     A value of 0 will check if the queue is empty and always return
>> >     immediately.
>> >
>> > In udev-147 (used on rhel6), this was the behavior. If timeout was 0,
>> > is_timeout was set and settle was returning with rc=1.
>> >
>> > This behavior changed in:
>> >
>> > http://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=ead7c62ab7641e150c6d668f939c102a6771ce60
>> >
>> > After this commit, zero timeout results in unlimited wait. Since this
>> > patch did not
>> > change the manual or the online help, and the commit message says:
>> > "udevadm: settle - kill alarm()", I guess this was unintended change.
>> >
>> > I don't see the use case for disabling the timeout, so it seems that
>> > we should fix
>> > this, restoring the behavior before this commit.
>> >
>> > What do you think?
>>
>> Ok, this is on me, sorry for that. I tried to keep the behavior from
>> before the code-removal. I wasn't aware that this was not how it is
>> documented.
>>
>> I'm actually not sure whether that was an intended change. It does not
>> look like it was, indeed. Maybe Kay or Tom know more.. I have no idea
>> whether timeout=0 is used in the wild.
>>
>> I'll stall your further patches until we've decided on this.
> What's the status here?

This is already fixed in -git. Original behavior is restored.

Thanks
David