Implement OpenRC service

[BalkanMadman]

This is still a draft.
This PR adds two flags to configure script:

• --with-openrc: toggles on or off (default — off) OpenRC service installation and udev activation via that. Conflicts with systemd, so the latter must be disabled explicitly — --with-openrc --without-systemd
• --with-rcservicedir: specifies directory where to install service file. Defaults to $sysconfdir/init.d (which is /etc/init.d)

I need the most feedback on which options should be used with usbmuxd. The only one used here is --user usbmux. Maybe --udev should be added? I don't know usbmuxd architecture that well, so a few advises on this matter won't hurt much :)

[BalkanMadman]

Issue: #210

[nikias]

What's the status of this?

[BalkanMadman]

Oh, I am sorry it took me so long, still being on vacation I haven't got the chance to actually test the commit. I will be able to fully work on this in two weeks.

The reason why it is still a draft in the lack of proper testing. This is based on master, which requires libimobiledevire-glue that is not yet packaged by Gentoo (which itself depends on libplist 2.3.0 that also happens to not be packaged), so you know. But it does look good when is installed to a DESTDIR (the fact on itself may not be enough to merge the PR).

One thing left, which does not depend on me is the flags used in the service script. Could you confirm/verify I used the correct ones?

usbmuxd/openrc/usbmuxd.in

Line 8 in 881f59a

command_args="--user usbmux"

In addition to that I would also like to get some feedback on code styling and change what is deemed necessary

[nikias]

One thing left, which does not depend on me is the flags used in the service script. Could you confirm/verify I used the correct ones?

usbmuxd/openrc/usbmuxd.in

Line 8 in 881f59a

command_args="--user usbmux"

Yes, that is correct. It's -U or --user.

In addition to that I would also like to get some feedback on code styling and change what is deemed necessary

Looks good to me.

[blshkv]

The reason why it is still a draft in the lack of proper testing. This is based on master, which requires libimobiledevire-glue that is not yet packaged by Gentoo (which itself depends on libplist 2.3.0 that also happens to not be packaged), so you know. But it does look good when is installed to a DESTDIR (the fact on itself may not be enough to merge the PR).
med necessary

FYI, libimobiledevice-glue is here:
pentoo/pentoo-overlay@f5164d2
libplist 2.3.0 is in the main tree.

Hope to see some progress soon.

[blshkv]

I checked the code I realised that you run "/etc/init.d/usbmuxd start" from udev rule? This is just wow ...
Please don't do it. Learn how to do it properly instead.

[BalkanMadman]

I checked the code I realised that you run "/etc/init.d/usbmuxd start" from udev rule? This is just wow ... Please don't do it. Learn how to do it properly instead.

udev(7) specifies the only way to run daemons from udev and that is using SYSTEMD_WANTS property, which, logically, has no effect on OpenRC system (or any non-systemd init system).
Quoting:

Starting daemons or other long-running processes is not
allowed; the forked processes, detached or not, will be
unconditionally killed after the event handling has finished.
In order to activate long-running processes from udev rules,
provide a service unit and pull it in from a udev device
using the SYSTEMD_WANTS device property. See
systemd.device(5) for details.

/etc/init.d/usbmuxd is a short-running process that immediately exits after starting the daemon (the daemon itself is not child of the udev process but of the OpenRC service system). I might be mistaken somewhere, so feel free to correct me if it is the case.
A similar, albeit slightly different in implementation, method of launching daemons by udev is even present on the Gentoo wiki here.

From my testing with this patch applied to usbmuxd-1.1.1, it seems to have no effect on the occurrence of the bug. Yet, this seems to be much more compliant way to execute daemons with udev and should theoretically be merged.
The bug most likely will not be fixed by this, so the commit should be regarded as an enhancement, not a bug fix.
I will work on isolating and locating the root cause.

[BalkanMadman]

And the commit itself should be cleaned up a bit...

[BalkanMadman]

I suppose this is ready to be reviewed

[blshkv]

ok, maybe I'm wrong about running openrc. I was sure that udev script should execute its own /lib/udev/ only. But I found sys-apps/pcsc-lite, as an example, which installs /lib/udev/pcscd.sh and runs the following:

# make sure openrc is managing services
if [ ! -d /run/openrc ]; then
        exit 0
fi

IN_HOTPLUG=1 /etc/init.d/pcscd --quiet start

You might want to check what IN_HOTPLUG does, and add --quiet

[BalkanMadman]

ok, maybe I'm wrong about running openrc. I was sure that udev script should execute its own /lib/udev/ only. But I found sys-apps/pcsc-lite, as an example, which installs /lib/udev/pcscd.sh and runs the following:

# make sure openrc is managing services
if [ ! -d /run/openrc ]; then
        exit 0
fi

IN_HOTPLUG=1 /etc/init.d/pcscd --quiet start

You might want to check what IN_HOTPLUG does, and add --quiet

I have already added the --quiet option:

usbmuxd/configure.ac

Lines 118 to 119 in 507cf94

	udev_activation_rule="RUN+=\"@rcservicedir@/usbmuxd start --quiet\""
	udev_deactivation_rule="RUN+=\"@rcservicedir@/usbmuxd stop --quiet\""

For a service marked with the IN_HOTPLUG to be displayed as, well, hotplugged, its name must be specified manually in the main OpenRC config /etc/rc.conf (AFAIK, it can not be set per-service in /etc/conf.d), which is rather uncomfortable and cumbersome for most users. I suppose, it is practically useless to install a whole shell script with no effect in 99% cases.

[BalkanMadman]

I have slightly reworded the commit message to better reflect what the change actually does.
@nikias, could you have a look and merge this PR?