~alpine/users

3 3

Eudev/OpenRC and long RUN+= script

Details
Message ID
<cb161c38-cf52-550f-2025-031e609402d8@ipik.org>
DKIM signature
missing
Download raw message
Hi,

I need to run some script as a result of a eudev rule with:
RUN+=path/to/myScript param
Unfortunately that script may take some time to complete,
which may cause problems to eudev.
In Systemd world, SYSTEMD_WANTS can be used for that [1]
Is there anything equivalent in OpenRC service world?

Or is the only alternative to have some intermediate helper script
RUN+=path/to/MyHelperScript param
with:
cat MyHelperScript
#!/bin/sh
path/to/myScript $1 &

Thanks for any suggestion.

[1] http://jasonwryan.com/blog/2014/01/20/udev/
Laurent Bercot <ska@skarnet.org>
Details
Message ID
<em8b31c8c5-5607-48af-bbe4-5ee406ff4ffb@3adf1e88.com>
In-Reply-To
<cb161c38-cf52-550f-2025-031e609402d8@ipik.org> (view parent)
DKIM signature
missing
Download raw message
>I need to run some script as a result of a eudev rule with:
>RUN+=path/to/myScript param
>Unfortunately that script may take some time to complete,
>which may cause problems to eudev.

  How long are we talking about? If it's 20 seconds, eudev should be
able to handle it. If it's a minute or so, and eudev is locked while
your script is running, and/or you're losing events because the
netlink queue is overflowing, that's another question.


>In Systemd world, SYSTEMD_WANTS can be used for that [1]
>Is there anything equivalent in OpenRC service world?

  Tying dynamic events (such as a device add/remove event handled by
the device manager) to a service manager is difficult. systemd can do
it because it's complex and the systemd-udevd device manager is
integrated with it on purpose; for an independent service manager such
as OpenRC, it's much harder.

  If you need to trigger some script that does *not* have anything to
do with handling an event (i.e. the device being functional does not
depend on your script completing), then running it in the background
is a good idea:

>Or is the only alternative to have some intermediate helper script
>RUN+=path/to/MyHelperScript param
>with:
>cat MyHelperScript
>#!/bin/sh
>path/to/myScript $1 &

  It's not the only alternative, but it's a viable solution.

  If you wanted more integration with the service manager, you would need
to do explicitly what systemd allows you to do implicitly via an
environment variable: write a valid openrc service file for your script,
and start this service in your eudev rule via something like
"RUN+=/sbin/rc-service yourservice start".

--
  Laurent
Details
Message ID
<3837b1b4-520e-8644-88cd-0e441adeefe2@ipik.org>
In-Reply-To
<em8b31c8c5-5607-48af-bbe4-5ee406ff4ffb@3adf1e88.com> (view parent)
DKIM signature
missing
Download raw message
Thank you very much for your detailed answer Laurent.

>  How long are we talking about?
That's a few seconds in general. There are 2 main usecases:

A) detect AudioCD inserts and ejects (change events), in order
to construct playlists and manage a media player accordingly.
This sometimes takes time depending on cdparanoia scan and
media quality (few secs to ~10sec)

B) detect paired Bluetooth devices incoming connections (add events)
for AVRCP or BT remote control input devices, in order to
relaunch busybox acpid on new inputs, so that key events are
then processed. (It indeed misses the first key event though).
It also handles BT speaker management (handover/switch)

Case A has an input parameter, so I may retain the helper
script approach to background it, although it could be
adapted for a service spin.

Case B may fire-up multiple instances of same script as one
BT peripheral often opens several inputs at once (script filters
them-out): this may not be suitable for service approach either.

Thanks.
macmpi
Laurent Bercot <ska-devel@skarnet.org>
Details
Message ID
<em2699bf9b-e009-432a-ac5a-d584d681f1a1@3ec63143.com>
In-Reply-To
<3837b1b4-520e-8644-88cd-0e441adeefe2@ipik.org> (view parent)
DKIM signature
missing
Download raw message
>A) detect AudioCD inserts and ejects (change events), in order
>to construct playlists and manage a media player accordingly.
>This sometimes takes time depending on cdparanoia scan and
>media quality (few secs to ~10sec)
>
>B) detect paired Bluetooth devices incoming connections (add events)
>for AVRCP or BT remote control input devices, in order to
>relaunch busybox acpid on new inputs, so that key events are
>then processed. (It indeed misses the first key event though).
>It also handles BT speaker management (handover/switch)

  These two cases are different.

  Case A is just that you want some script triggered when an event
occurs. For this, udevd is only the program spawning your script;
your script is a generic consumer of the event, and doesn't have
anything to do with device creation and management - so you need to
get out of udevd's way as fast as possible and let it keep doing its
job. Running your script in the background is a good idea here.

  Case B has direct impact on your event management flow: you want to
relaunch acpid *before* handling the next event, to make sure that it
is correctly processed. The acpid relaunch needs to be synchronous:
you cannot run this in parallel. And theoretically, the script should
wait until acpid notifies that it is ready, then your script could
exit and let udevd proceed with the next event.

  I'm afraid there's no one-size-fits-all solution to your issue. You
could try spawning the user stuff in the background, but keeping the
device management part synchronous.

  Again, dynamic event management is difficult, and that's why 
alternative
solutions are slow to come by.

--
  Laurent
Reply to thread Export thread (mbox)