systemd is a mess. A while ago I tried writing a script for CD ripping that ran when udev detected a music CD in the optical drive, ripped the CD, then ejected the disk.
This kept failing. It turned out to be systemd having a hardcoded timeout of something like 30 seconds on any process launched by udev, that couldn't be changed without recompiling it from source, or having it fork off some other process group that lacked this limitation.
From what I can tell, systemd has some of the worst sort of developer myopia, where whole swaths of legitimate use cases are actively destroyed.
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.
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.
This kept failing. It turned out to be systemd having a hardcoded timeout of something like 30 seconds on any process launched by udev, that couldn't be changed without recompiling it from source, or having it fork off some other process group that lacked this limitation.
From what I can tell, systemd has some of the worst sort of developer myopia, where whole swaths of legitimate use cases are actively destroyed.