mediasrv startup process

[derabbink]

I installed the latest driver (May 10, 2014) on ubuntu 14.04 and ran ps aux | grep mediasrv. I found that the mediasrv driver process is running as user root, and I was wondering if this was really necessary.

So, I started looking around my system where this process is started. I found two possible places:

• /etc/udev/rules.d/80-mediasrv-eeti.rules
  Inside this file, it sais:
  SUBSYSTEM=="usb", ACTION=="add", RUN+="/opt/bin/mediaclient --start=5 --systemdcheck"
  Which made me check the systemd directory.
• /etc/systemd/system/multi-user.target.wants/sundtek.service which is a soft link to /usr/lib/systemd/system/sundtek.service
  First of all, this link target does not exist, so the installer must be broken/buggy for my system.
  What does exist, is the file /lib/systemd/system/sundtek.service (no /usr/ at the beginning)
  The contents of this file are (in part) ExecStart=/opt/bin/mediaclient --start=4 and ExecStop=/opt/bin/mediaclient --shutdown

I'm not entirely sure on this, but the way I think this works is the following:
mediasrv is not started during boot by the /lib/systemd/system/sundtek.service file, because the soft link /etc/systemd/system/multi-user.target.wants/sundtek.service points to the wrong file.
That leaves udev to start the service when hotplugging. Is this correct?

Coming back to my initial curiosity: "Does mediasrv have to run as root?", I think not (right?), but I'm reluctant to edit the /etc/udev/rules.d/80-mediasrv-eeti.rules file, if the service is supposed to be started by systemd. In case of the latter, can I just fix the symlink to the systemd script and change that to run mediasrv (via mediaclient) as a different user?

[Sundtek]

mediasrv has to run as root in order to access the USB Stack.
Of course you can move it to another user however this requires some different system setup.
Remember regular drivers even run in kernel/system space and have much greater permissions than our driver.
The driver communicates via raw USB Messages, if normal users would have access to that they would even be able to damage the content of a usb harddisk by sending raw usb commands.

The systemd paths are according to Redhat I think; they are not linked because you installed it on Ubuntu.

The startscripts depend on various systems, on Ubuntu the default is to start the driver via udev.

You are free to update or modify those start scripts of course. We do not only support ubuntu and the way it is done at the moment is the best one across multiple distributions.

Also the driver has very high backward compatibility, down to 2.6.15 (Linux systems from 2006).

[derabbink]

Thanks for the detailed response.
What I have learned from that, is that essentially the systemd script/symlink could be deleted, as it does not play a role on ubuntu; even though the --systemdcheck option is provided in the udev script.

I tried to understand the --systemdcheck option, but mediaclient --help only sais "start via systemd if available". I don't know what that means.
The mediaclient wiki page does not mention this option either.

[Sundtek]

I think if systemd is available mediaclient will only trigger the systemd client command to start the driver via systemd. Otherwise mediaclient --start will start the driver directly in the background (in that case the mediaclient process would be the parent process of the driver, in case of systemd - systemd will be the parent of the driver - systemd also puts it into a cgroup etc).

If mediaclient would directly do that with udev on newer Redhat systems, the udev system will kill the driver after a few seconds. Systemd introduced some very heavy changes to the daemon startup mechanism, it's complicated to find a common way across most systems. For us it's only important that the mediasrv process starts up somehow.