improving a daemon script

[DaggyStyle]

Greetings,

I have simple script that runs in the background (launches by an openrc script)m the script stays up using a endless loop with sleep of 1 sec and reacts to signals sent via udev events (add and remove).
ideally, I'd like to remove the service and relay only on udev events.
the main issue is that the add event needs to run several commands a few seconds after udev finished handling the add event.

any ideas how I can achieve it? I've tried running fork from within the script when I called it from the udev event handler but it seems that udev waits until all the children of the script it runs to end before it continues.

[DaggyStyle]

one possibility is to add a sysfs entry which will run <path to script> foo when the udev rule does /bin/echo foo > <path to sysfs entry>
not sure if it will work. thought? I know it inst that safe kernel wise

[GDH-gentoo]

ideally, I'd like to remove the service and relay only on udev events.
the main issue is that the add event needs to run several commands a few seconds after udev finished handling the add event.

I don't understand. An udev rule that matches the event you are interested in and contains RUN="your-script" does not work?

[Hu]

That worked fine, once. Modern udev is very specific about how they don't want you running "long running" jobs. At least for systemd-udevd, I think they actually take steps that make this not work. I don't know if udev under openrc, or eudev under openrc, have the same problem. The canonical answer from the systemd people is to use a udev rule that triggers a systemd service to do the real work. That won't work under openrc, where there is no systemd service to trigger.

DaggyStyle: how exactly did you make the script fork?

[javeree]

I believe the best way to start a long running script under udev is RUN="echo myscript | at now"
(required atd daemon)

[GDH-gentoo]

That worked fine, once. Modern udev is very specific about how they don't want you running "long running" jobs. At least for systemd-udevd, I think they actually take steps that make this not work.

Yeah, as far as I can tell, both systemd-udevd and eudev's udevd kill the spawned process if it runs for too long, but "too long" is a time interval of configurable duration that defaults to 3 minutes.

I believe the best way to start a long running script under udev is RUN="echo myscript | at now"
(required atd daemon)

I don't think that will work; as far as I can tell the value assigned to RUN is not parsed by a shell, so the pipe character might not work as expected. RUN="/bin/sh -c 'echo myscript | at now'" on the other hand might, but I don't see at the moment why simply calling the script won't work.

EDIT to clarify: What I'm expecting the script spawned by the udev rule to do is running the per-event "several commands" referred to in the OP, not a long-lived process. I understand that the long-lived process spawned by an OpenRC service script is what the OP wants to get rid of.

[DaggyStyle]

ideally, I'd like to remove the service and relay only on udev events.
the main issue is that the add event needs to run several commands a few seconds after udev finished handling the add event.

I don't understand. An udev rule that matches the event you are interested in and contains RUN="your-script" does not work?

it runs well but as explained above, the device takes a few minutes to function after the add rule was matched.
the script waits for 5'6 minutes for a specific "signal", if within that timeframe the specific "signal" is received, I continue with the next cmds, if not, it bails out.

That worked fine, once. Modern udev is very specific about how they don't want you running "long running" jobs. At least for systemd-udevd, I think they actually take steps that make this not work. I don't know if udev under openrc, or eudev under openrc, have the same problem. The canonical answer from the systemd people is to use a udev rule that triggers a systemd service to do the real work. That won't work under openrc, where there is no systemd service to trigger.

DaggyStyle: how exactly did you make the script fork?

tried &, nohup and even openrc pre_up, all of them worked.

I believe the best way to start a long running script under udev is RUN="echo myscript | at now"
(required atd daemon)

thanks for the sugggestion, will look at it.

That worked fine, once. Modern udev is very specific about how they don't want you running "long running" jobs. At least for systemd-udevd, I think they actually take steps that make this not work.

Yeah, as far as I can tell, both systemd-udevd and eudev's udevd kill the spawned process if it runs for too long, but "too long" is a time interval of configurable duration that defaults to 3 minutes.

I believe the best way to start a long running script under udev is RUN="echo myscript | at now"
(required atd daemon)

I don't think that will work; as far as I can tell the value assigned to RUN is not parsed by a shell, so the pipe character might not work as expected. RUN="/bin/sh -c 'echo myscript | at now'" on the other hand might, but I don't see at the moment why simply calling the script won't work.

EDIT to clarify: What I'm expecting the script spawned by the udev rule to do is running the per-event "several commands" referred to in the OP, not a long-lived process. I understand that the long-lived process spawned by an OpenRC service script is what the OP wants to get rid of.

the main issue is that udev waits for the child, that is want I need to fix, e.g. udev runs the script and continues while the script continues in the background.

[ff11]

...
the main issue is that udev waits for the child, that is want I need to fix, e.g. udev runs the script and continues while the script continues in the background.

Yes, but what if udev calls a script just_trigger.sh and you call inside it the real script, childless (using something like ( script_that_wait_and_do_things.sh & ), or disown, yes, bash ^_^), which will wait and do the job, but it won't block the normal return from the just_trigger.sh script and let udev go its way. You can even do a check (inside script_that_wait_and_do_things.sh) if you want only one instance to run and working at a time.

[DaggyStyle]

...
the main issue is that udev waits for the child, that is want I need to fix, e.g. udev runs the script and continues while the script continues in the background.

Yes, but what if udev calls a script just_trigger.sh and you call inside it the real script, childless (using something like ( script_that_wait_and_do_things.sh & ), or disown, yes, bash ^_^), which will wait and do the job, but it won't block the normal return from the just_trigger.sh script and let udev go its way. You can even do a check (inside script_that_wait_and_do_things.sh) if you want only one instance to run and working at a time.

not sure I follow, if I have script a.sh, inside a.sh calls func fa like this:
fs &
then udev will wait. but I change is to:
( fa & ), a.sh will exit and fa will run in the background?

[ff11]

...
not sure I follow, if I have script a.sh, inside a.sh calls func fa like this:
fs &
then udev will wait. but I change is to:
( fa & ), a.sh will exit and fa will run in the background?

I never tested it with functions, just with real scripts, but the idea is this:
In ( script_that_wait_and_do_things.sh & ), the (..) creates a child process, and & creates a grandchild process. When the child process dies, the grandchild process is inherited by init.

[DaggyStyle]

ok, I'l try this suggestion, hope it works.

thanks.