3 ms·
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 sys
by rlpb 9y ago
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.
- jononor 9y agoAnd I am fairly sure that this design predates systemd by several years.
- deleted 9y ago[deleted]
- zdw 9y agoI 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.
- inopinatus 9y agoTo 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 http://www.itp.uzh.ch/~dpotter/howto/daemonize
- mst 9y agosystemd's session killing stuff will happily kill anything that's been daemonised by the standard approach :(
- JdeBP 9y agoActually, 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.