Discussion:
rfc: udev should be able to re-exec itself
William Hubbs
2012-06-01 23:45:43 UTC
Permalink
All,

currently udev does not have a way to restart itself. This would be a
useful feature, because we could then use this command when we upgrade
or downgrade udev on user's systems so that the most current version of
udev is always running.

One of gentoo's developers did suggest a patch quite a while back, but
some how it got lost in the shuffel. This patch will not apply now, but
it gives the impression that something like this could be added very
easily [1].

Thoughts anyone?

Thanks,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=129204#c7
Kay Sievers
2012-06-04 13:43:58 UTC
Permalink
Post by William Hubbs
currently udev does not have a way to restart itself. This would be a
useful feature, because we could then use this command when we upgrade
or downgrade udev on user's systems so that the most current version of
udev is always running.
One of gentoo's developers did suggest a patch quite a while back, but
some how it got lost in the shuffel. This patch will not apply now, but
it gives the impression that something like this could be added very
easily [1].
Thoughts anyone?
We do not want daemons to re-execute themselves. It's far more
complicated than usually expected, and in most cases it should be
avoided.

The problem of interruption-free upgrades is in most cases solved with
systemd's socket activation. But I don't think any distribution uses
that possibility when they upgrade udev today, but they easily could,
all the things are there to make it work.

Udev should not re-execute itself, but stopped, installed, and
restarted. If you want fancy upgrade setups, use an init system that
supports that properly while keeping things simple, and which allows
interruption-free restarts by keeping the sockets open.

Don't hack up daemons with half-baken things; it's *really* hard to get right.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Loading...