Arch Linux User Repository

In the context of systemd "disabled" does not mean that the service cannot be started, but just that systemd won't start the service automatically when booting (but it can still be triggered manually or via udev, as in this case). If you want to prevent the service from starting, use "systemctl mask" instead of "systemctl disable".

Yes that could explain the behavior that I see. I would prefer once disabled it will preserve reboot. I have had calltrace and was checking if it was from DVB-S2 device or something else thus sundtek service was disabled.

optdepends sounds like a good solution, I'll implement that. Even when the service is disabled, udev will start it, if it detects a compatible device (configured in sundtek.rules). Does this explain the behaviour that you see?

I got an answer from sundtek support: libpulse or libalsa are for FM Radio needed. An libc is in normally always there. So maybe to put them as optdepends=() ?

What I found weird, is even I disable both systemd service, after restart they are enabled again. Yes I did stop and disable services, could it be that they are copied to wrong location. I will test without both dependencies, but I cannot really rest as my hardware does not receive signal from LNB and thus i am unable to know if it works after or not. An replacement is on its way.

Well, details I cannot know without owning any sundtek hardware.

Thanks Bevan. As far as I can see, your service file is identical to the one that this package already ships, except for the Restart=always line, that you seem to need for your restart script to work. I tried to implement that functionality using a second systemd service (sundtek-restart.service), so that this is probably not necessary here. CReimer, the custom service files are necessary as long as upstream ships ineffective service files, that cannot even detect whether the service is still running or has crashed. The same goes for the custom udev rules, where the upstream variant triggers for any USB device instead of properly restricting to supported products (e.g. via VID/PID filtering).

I once created my own package using a custom service file which I find more appropriate than the one included upstream. It contains a lot of other differences, too, but you may have a look: http://bit.ly/1ITAaAQ

Well. I'm no longer completely sure, why I added these dependencies. I don't own any sundtek device, which is why I dropped this PKGBUILD from vdr4arch in the first place. I'm interested in fixing this PKGBUILD, but I can't test it afterwards. sundtek.service, sundtek.rules and sundtek-restart.service doesn't seem to be necessary anymore. sundtek provides a service file for systemd. Unfortunately it's Type=oneshot which doesn't make any sense. The mediasrv tools seems to have a parameter which would make it compatible with Type=forking with the advantage that following daemons can wait until the sundtek driver is settled.

Good question. These dependencies were added by Christopher during the short period where he maintained this package. I merely kept them after I took over the package again, believing that this change was necessary. But I can see that the binary package built by this PKGBUILD contains for example its own copy of libpulse.so, so it might well be that the dependencies are not necessary. Could you try to install the package without the dependencies (just remove the depends= line from the PKGBUILD) and tell me whether it still works? Then I could remove them. I also prefer using the package manager instead of running unauthenticated scripts as root. The result of this package should be mostly identical to what is achieved by Sundtek's script, though some things have been improved (e.g. the systemd integration, hence the extra .service files).