On Tue, May 26, 2009 at 20:05, Alan Jenkins <alan-jenkins@xxxxxxxxxxxxxx> wrote: >> The event runs all programs serialized, one after the other, can't we >> just kill the program that does not return in time, and wait for it to >> cleanup the process, instead of just exiting the event process? > > That makes sense if you also change the timeout model - from per-event > timeouts, to per-command timeouts. We can still track how long we a running and use that timeout when waiting for the actual program to finish, right? > The second fork is cheap, because it's a vfork. But if you like > per-command timeouts, I would be happy to see it go away. I guess, it's simpler to understand and vfork() is something that even POSIX removed from the spec. :) > I'm not sure about killing. Do we need to escalate to SIGKILL? Do we > e.g. allow half the timeout before sending SIGTERM, then another half > before sending SIGKILL? I guess a few seconds would be good enough before we try to finally KILL it. > The process could even be unkillable - is it ok > to block after SIGKILL, or do we need another timeout? Hmm, yeah, maybe we just block. I don't remember any problems with the timeouts, they are mainly there to prevent bad things that make udev operations unreliable like people running apps with user interfaces from udev rules, which we see every other month. So I guess killing would be the right thing to do anyway. :) > I could keep a list of timed out processes instead, and reap them on > SIGCHLD. Would that be better? You mean as an alternative to blocking the event process? > There are other workarounds for the lack of a timeout in sys_wait(), so > I don't think that's a problem. We can require that commands close > stdout & stderr pipes when they exit - i.e. do not pass them on to a > long-running child. (At the moment there's a debian script "net.agent" > which has to do this for debug mode - it would need fixing to always do it). I don't think we can really assume anything from called programs. :) Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
