This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Recently patch from Hannes landed on systemd-devel and Kay has already merged it upstream. Zdenek, do you think it would solve LVM2 issue?

http://lists.freedesktop.org/archives/systemd-devel/2014-July/021601.html

(In reply to Michal Sekletar from comment #3)
> Recently patch from Hannes landed on systemd-devel and Kay has already
> merged it upstream. Zdenek, do you think it would solve LVM2 issue?
> 
> http://lists.freedesktop.org/archives/systemd-devel/2014-July/021601.html

Unfortunately, it won't. It's just a global timeout to use for udevd daemon. The same thing can be done via existing udev rule for each event separately and we're already using it (OPTIONS+="event_timeout=180").

The problem here is that we just don't know what the safe value should be for the number of seconds (since the environments may differ a lot when it comes to the number of devices/performance/things running in parallel that slow down the udev processing). It may happen that even the event_timeout=180 is not enough.

There's still a possibility the event processing is killed because of timeout. The requirement in this report is to provide a way to detect such situations somehow - that the event processing has not finished properly and that the udev db content may contain improper/old information that does not reflect the actual state. As Zdenek already commented in comment #0, we need to know this information somehow and current udev interface does not exhibit this.

As already commented in bug #918511, the best would if there's a possibility to mark the udev db as incomplete/dirty and to have a possibility to run a cleanup/notification rule on timeout so the rest of the system knows that something went wrong and the tools relying on udev/udev db can react to this situation (providing cleanup, error/warning messages etc.).

The udev worker timing out is a recurring issue.

As scripts forked by udev rules taking more than 30s are considered buggy we need to start gathering information about all these bugs. So the first thing is to make these issues traceable and sending SIGKILL is not helpful at all.

Make SIGSEGV a default please so a core is dumped.

If SIGSEGV can not be made default (And why it would not?) I want at least to be able to override the signal.

(In reply to Peter Rajnoha from comment #4)
> There's still a possibility the event processing is killed because of
> timeout. The requirement in this report is to provide a way to detect such
> situations somehow - that the event processing has not finished properly and
> that the udev db content may contain improper/old information that does not
> reflect the actual state. As Zdenek already commented in comment #0, we need
> to know this information somehow and current udev interface does not exhibit
> this.

This should be improved now. The killed worker will cause the database content
to be cleared and the raw kernel event is forwarded to tell userspace that udev
no better idea about the device:

  http://cgit.freedesktop.org/systemd/systemd/commit/?id=6969c349df91a3cc5fc2cf559a14e32a84db969d

We still miss a way to specify a rule that would be run on the timeout.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.