On Mon, Jan 30, 2012 at 22:24, Karl O. Pinc <kop@xxxxxxxx> wrote: > On 01/28/2012 10:23:43 PM, Kay Sievers wrote: > >> Mounting filesystems is just not simple enough to do that in udev, >> you >> need a real service to do that properly. Udev rules are just not the >> right tool for the job, and very likely never will be. > > It occurs to me that udev could provide an RUN-like key that > would not only run but would also detach the new process, > as a favor to long-running RUNed processes so that > each does not have to code it's own detach. No, udev is not supposed to ever directly start long running system services or daemons. It has intentionally no support for that. Services who need to detach from udev rules are simply broken. Udev is not an init system or service manager, and should not become one. Systemd or upstart, or whatever else that works like these tools, should be used if automatic start of services, based on kernel device events, is needed. Udev has a pretty advanced netlink-based event-delivery and filter mechanism, and kernel device enumerator for services to use to. It's trivial to use from almost any programming language. And that's the right point to hook a tool into kernel device events, and not by adding udev rules to fork off tools to run complex operations. It is just plain wrong to continue anything like the dirty hacks which are mentioned earlier in this mail thread. They not only risk data loss and filesystem damage for users, they are also conceptually wrong for many other reasons. Services need to be started as a direct child processes of and not inherit udev's execution context. Services need to handle all sorts of failures, guard against races caused by running multiple instances of the same tool, need to offer job control, support manual and automatic restarting of the service, handle device surprise removal, must not hook into early boot operations and block or delay basic system setup, and and and ... None of that is provided by udev and very likely never will. It takes a lot more safeguards to reliably run a system management task, than what udev can provide here. 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
