[systemd-devel] [PATCH 2/2] udev: Allow detection of udevadm settle timeout

[Tom Gundersen]

On Sat, May 2, 2015 at 12:21 PM, Nir Soffer <nirsof at gmail.com> wrote:
> On Tue, Apr 21, 2015 at 12:41 AM, Tom Gundersen <teg at jklm.no> wrote:
>> On Mon, Apr 13, 2015 at 3:04 PM, Nir Soffer <nirsof at gmail.com> wrote:
>>> On Sat, Apr 11, 2015 at 6:58 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
>>>>> A program running this tool can detect a timeout (expected) or an error
>>>>> (unexpected), and can change the program flow based on this result.
>>>>>
>>>>> Without this, the only way to detect a timeout is to implement the timeout
>>>>> in the program calling udevadm.
>>>>
>>>> I cannot really see a use-case here. I mean, yeah, the commit-message
>>>> says it warns about timeouts but fails loudly on real errors. But
>>>> again, what's the use-case? Why is a timeout not a real error? Why do
>>>> you need to handle it differently?
>>>
>>> Timeout means that the value I chose may be too small, or the machine
>>> is overloaded. The administrator may need to configure the system
>>> differently.
>>>
>>> Other errors are not expected, and typically unexpected errors in an
>>> underlying tool means getting the developer of the underlying tool
>>> involved.
>>>
>>>> Anyway, if it's only about diagnostics this patch seems fine to me.
>>>
>>> Yes, it is mainly about diagnostics, and making it easier to debug and support.
>>
>> Wouldn't a better solution be to improve the udevadm logging? If we
>> change the exit codes this is basically ABI. Do we really want to make
>> such promises only for diagnostics?
>
> Improving logging is orthogonal, as it does allow the program to change
> the flow based the exit code.
>
> Adding a timeout exit code may break code using undocumented behavior,
> since the return code is not documented.

I don't really have a strong argument against this, except that we
should not add "ABI" without a strong usecase. So you mentioned that
you want this for diagnostics, to which my suggestion was to improve
the logging in udevadm itself. But are there other usecases? What is
the case where the external tool actually needs to change its
behavior?

Cheers,

Tom