udevsend fallback

udevsend fallback

[Kay Sievers]

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?

thanks,
Kay


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevsend fallback

[Harald Hoyer]

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?
> 
> thanks,
> Kay

Directly is better than nothing...

my 2¢,
Harald


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevsend fallback

[Greg KH]

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.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevsend fallback

[Harald Hoyer]

Btw, how about exit()ing udevd after, say half an hour in idle mode?


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevsend fallback

[Kay Sievers]

On Thu, May 13, 2004 at 09:51:15AM +0200, Harald Hoyer wrote:
> Btw, how about exit()ing udevd after, say half an hour in idle mode?

We had this already, but I've removed it. We can't know the first
sequence number after a udevd exit() - so we need to delay every first
event until the timeout happens.
So every first event _after_ any exit will be delayed, which is not
nice. Any better idea?

thanks,
Kay


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevsend fallback

[Greg KH]

On Thu, May 13, 2004 at 09:51:15AM +0200, Harald Hoyer wrote:
> Btw, how about exit()ing udevd after, say half an hour in idle mode?

Why?  It takes almost _no_ system resources if built with klibc (I think
2 pages of memory last time I looked).  Also, there is a long delay the
next time it gets launched, which is a bad thing from a user
perspective.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevsend fallback

[Kay Sievers]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

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 udev is unable to send the
event to udevd, we call the udevd binary instead of do nothing and exit.

thanks,
Kay

[-- Attachment #2: 01-udevsend-fallback.patch --]
[-- Type: text/plain, Size: 1931 bytes --]

===== udevsend.c 1.29 vs edited =====
--- 1.29/udevsend.c	Sun Mar 28 01:08:58 2004
+++ edited/udevsend.c	Fri May 14 12:55:50 2004
@@ -98,6 +98,26 @@
 	return 0;
 }
 
+static void run_udev(const char *subsystem)
+{
+	pid_t pid;
+
+	pid = fork();
+	switch (pid) {
+	case 0:
+		/* child */
+		execl(UDEV_BIN, "udev", subsystem, NULL);
+		dbg("exec of child failed");
+		exit(1);
+		break;
+	case -1:
+		dbg("fork of child failed");
+		break;
+	default:
+		wait(NULL);
+	}
+}
+
 int main(int argc, char* argv[])
 {
 	struct hotplug_msg msg;
@@ -109,14 +129,12 @@
 	int retval = 1;
 	int loop;
 	struct timespec tspec;
-	int sock;
+	int sock = -1;
 	struct sockaddr_un saddr;
 	socklen_t addrlen;
 	int started_daemon = 0;
 
-#ifdef DEBUG
 	init_logging("udevsend");
-#endif
 	dbg("version %s", UDEV_VERSION);
 
 	subsystem = get_subsystem(argv[1]);
@@ -150,7 +168,7 @@
 	sock = socket(AF_LOCAL, SOCK_DGRAM, 0);
 	if (sock == -1) {
 		dbg("error getting socket");
-		goto exit;
+		goto fallback;
 	}
 
 	memset(&saddr, 0x00, sizeof(struct sockaddr_un));
@@ -168,22 +186,21 @@
 				(struct sockaddr *)&saddr, addrlen);
 		if (retval != -1) {
 			retval = 0;
-			goto close_and_exit;
+			goto exit;
 		}
-		
+
 		if (errno != ECONNREFUSED) {
 			dbg("error sending message");
-			goto close_and_exit;
+			goto fallback;
 		}
-		
+
 		if (!started_daemon) {
-			dbg("connect failed, try starting daemon...");
+			info("starting udevd daemon");
 			retval = start_daemon();
 			if (retval) {
-				dbg("error starting daemon");
-				goto exit;
+				info("error starting daemon");
+				goto fallback;
 			}
-			
 			dbg("daemon started");
 			started_daemon = 1;
 		} else {
@@ -193,9 +210,14 @@
 			nanosleep(&tspec, NULL);
 		}
 	}
-	
-close_and_exit:
-	close(sock);
+
+fallback:
+	info("unable to connect to event daemon, try to call udev directly");
+	run_udev(subsystem);
+
 exit:
+	if (sock != -1)
+		close(sock);
+
 	return retval;
 }

Re: udevsend fallback

[Greg KH]

On Fri, May 14, 2004 at 01:22:06PM +0200, Kay Sievers wrote:
> 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 udev is unable to send the
> event to udevd, we call the udevd binary instead of do nothing and exit.

Applied, thanks.

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel