[systemd-devel] [PATCH] udev: warn instead of killing kmod loading

[Kay Sievers]

On Sat, Aug 9, 2014 at 4:16 AM, Luis R. Rodriguez
<mcgrof at do-not-panic.com> wrote:
> The purpose of commit e64fae55 (January 2012) on systemd was
> to introduce a timeout send to hell drivers that are not using
> asynch firmware loading. That commit actually would not have
> triggered in full effect on udev's usage of kmod for module
> loading until commit 786235ee was merged on Linux (Nov 2013).
>
> As it is today [ systemd e64fae55 + kernel e64fae55 ] will trigger
> a SIGKILL to udev's usage of kmod for module loading after a 30
> second timeout. Hannes modified systemd through commit 9719859c
> to enable a custom timeout. A different timeout value can only
> prevent a kill after a maximum amount of time is known to be
> required for a system.
>
> Penalizing a device driver for not using asynch firmware loading
> by killing it and preventing it from loading *might* have originally
> been reasonable but its not the only reason why some drivers might
> take more than 30 seconds to load. Some drivers might actually
> require take over 30 seconds on just writing the firmware to the
> hardware. The worst case scenario however would be to run into
> storage drivers which might go over the timeout value in which
> case currently the system would simply be unbootable. Fixing
> drivers should be our *top priority* but the current state of
> affairs has proven to make it very difficult to debug why a
> driver is failing to load.
>
> Instead of always forcing a kill lets only warn for workers
> handling kmod. This should enable easier methods for determining
> which drivers need fixing and the logic would only be used on
> workers dealing with kmod module loading.

Nobody wanted to send anything to hell, penalize or force anything
anywhere. This kind of language is absolutely not welcome here.

Every operation in systemd, unless specified otherwise, has and needs
to have a timeout. The 30 seconds were arbitrarily chosen just to be
smaller than the kernel's own 60 second timeout for the userspace
firmware loader. Now that userspace firmware loading is gone, this
does not apply anymore.

Like everywhere else, we should keep the timeout handling by default.
If 60 seconds are too short, we might want to set it to something
else.

Kay