diff options
author | kay.sievers@vrfy.org <kay.sievers@vrfy.org> | 2004-05-14 23:18:41 -0700 |
---|---|---|
committer | Greg KH <gregkh@suse.de> | 2005-04-26 21:35:18 -0700 |
commit | 28e169f067aa96b406342677922e34e7361a7d1b (patch) | |
tree | aac07716263341479dd6435e074f6939526f858c /TODO | |
parent | 1eae2f3f712ff839bf80721bf9c44a76a78460dc (diff) |
[PATCH] udevsend fallback
On Tue, May 11, 2004 at 04:54:44PM -0700, Greg KH wrote:
> On Tue, May 11, 2004 at 01:16:41PM +0200, Kay Sievers wrote:
> > Hi,
> > the execution of udev depends on the proper fuction of udevd, the
> > serializing daemon. If we can't connect to udevd within a 20 second we
> > give up and the request to create a node is lost. Hope this never happens,
> > but a broken udevd may prevent udev from working.
> >
> > What do you think? Should we call the udev binary directly from udevsend
> > instead of discarding the event? This way we would create the node, regardless
> > of the state of udevd. It would be 20 seconds later and maybe not in the right
> > sequence order - but the node will propably be there.
> >
> > Does it sound sane? What do you think?
>
> That sounds like a good "failsafe" thing to do.
Here we go:
Add a fallback udev call to udevsend. If udevsend is unable to send the
event to udevd, we call the udev binary instead of doing nothing and exiting.
Diffstat (limited to 'TODO')
0 files changed, 0 insertions, 0 deletions