summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorkay.sievers@vrfy.org <kay.sievers@vrfy.org>2004-05-14 23:18:41 -0700
committerGreg KH <gregkh@suse.de>2005-04-26 21:35:18 -0700
commit28e169f067aa96b406342677922e34e7361a7d1b (patch)
treeaac07716263341479dd6435e074f6939526f858c /README
parent1eae2f3f712ff839bf80721bf9c44a76a78460dc (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 'README')
0 files changed, 0 insertions, 0 deletions