Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It sounds like you're blocking udev while your script executes, and instead you should start a service from your udev script and then exit. For example, see systemd-run(1).

> ...where whole swaths of legitimate use cases are actively destroyed.

Your use case is fine. Your implementation doesn't fit with udev's design; that's all.



I was having udev starting a separate ripping script as a background process, and it worked on pre-systemd udev systems.

systemd kills the entire udev process tree (all children) including the ripping script after 30 seconds.


Actually, it's udevd itself doing that. A regular child-killing rampage is built into its main loop. To avoid it, one must arrange to not run the desired program directly, but rather to make udevd activate another service that in turn runs the desired program.


To fix this, perhaps it'll need to fork and detach the session, as per the standard daemonisation sequence. c.f. http://www.itp.uzh.ch/~dpotter/howto/daemonize


systemd's session killing stuff will happily kill anything that's been daemonised by the standard approach :(


And I am fairly sure that this design predates systemd by several years.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: