Thomas Gleixner wrote:
> But then systemd/udev mutters:
>
> "You migh be able to work around the timeout with udev rules and
> OPTIONS+="event_timeout=120", but that code was maybe never used
> or tested, so it might not work correctly." [1]
>
> AFAICT from the ubuntu bug system [2] nobody bothered even to try that.
>
> And if the udev/systemd event_timeout option is broken it's way better
> to fix that one instead of hacking random heuristics into the kernel.
I haven't tried the event_timeout= option but I think it will not work.
The timeout is hard coded as shown below and there will be no chance for taking
the event_timeout= option into account.
---------- systemd-204/src/udev/udevd.c start ----------
(...snipped...)
/* check for hanging events */
udev_list_node_foreach(loop, &worker_list) {
struct worker *worker = node_to_worker(loop);
if (worker->state != WORKER_RUNNING)
continue;
if ((now(CLOCK_MONOTONIC) - worker->event_start_usec) > 30 * 1000 * 1000) {
log_error("worker [%u] %s timeout; kill it\n", worker->pid,
worker->event ? worker->event->devpath : "<idle>");
kill(worker->pid, SIGKILL);
worker->state = WORKER_KILLED;
/* drop reference taken for state 'running' */
worker_unref(worker);
if (worker->event) {
log_error("seq %llu '%s' killed\n",
udev_device_get_seqnum(worker->event->dev), worker->event->devpath);
worker->event->exitcode = -64;
event_queue_delete(worker->event, true);
worker->event = NULL;
}
}
}
(...snipped...)
---------- systemd-204/src/udev/udevd.c end ----------
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
