|
Michael Biebl: I wonder if nosh could be an option for non-linux. According to its website it supports native systemd service files. I have to admit though, I never looked at nosh myself, so I have no idea how far that "systemd support" goes. This caught my eye, so I thought that I'd demonstrate. Before getting to what I did, let's clear up some tangential points. Alec Leamas: The systemd setup [for lirc] is three different services, the sysV [setup] one. There is no systemd service directly corresponding to the sysV one. The Debian revision log says that that's not in fact true.
There have been three System 5 rc scripts since May 2014;
precisely so that there is a correspondence between
service names, according to the commentary. From a Debian point of view, I suspect that the answer that you'll get from all of the Debian people who actually look into the situation is that if Debian Maintainer Stefan Lippers-Hollmann is willing to continue doing this work to maintain System 5 rc scripts for your software, you should let xem. (-: I suggest that you should probably pay more attention to the
System 5 rc scripts, because your systemd units aren't up to
scratch and don't do as good a job. I discovered this by running
your Yes the nosh package can take this sort of thing and convert it
to native form. There's a detailed worked example of doing so on
the nosh WWW pages.
For lirc it was almost as easy as: JdeBP /tmp $ fetch 'http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/lircd.socket?format=raw' -o lircd.socket JdeBP /tmp $ fetch 'http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/lircd.service?format=raw' -o lircd.service JdeBP /tmp $ convert-systemd-units ./lircd.socket JdeBP /tmp $ sudo system-control start /tmp/lircd What resulted was a service that didn't start. Hence "almost". JdeBP /tmp $ svstat /tmp/lircd /tmp/lircd: stopped since 2016-01-16 23:06:12 +0000; 2m 1s ago. , initially started JdeBP /tmp $ It didn't start because the service unit was wrong. A quick check of the log revealed that the service was trying to
create a local-domain socket at [ -d "/run/lirc" ] || mkdir -p "/run/lirc" The systemd service unit file way of doing the same thing is: [Service] RuntimeDirectory=lirc So I edited that into your JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket JdeBP /tmp $ sudo system-control start /tmp/lircd Now I was hit by the fact that you'd hardwired the pathname JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket JdeBP /tmp $ sudo system-control start /tmp/lircd And it's up and running, converted from your socket and service
units into native service bundles, on nosh-managed PC-BSD 10.2. JdeBP /tmp $ svstat /tmp/lircd /tmp/lircd: running (pid 50174) since 2016-01-16 23:39:56 +0000; 6s ago. JdeBP /tmp $ There are several things that you probably should take note of
here. The converted service bundle uses UCSPI-TCP tools from the
toolset to set up the listening socket for lircd to inherit.
Unfortunately, even though this is lirc version 0.9.0, built
straight from the FreeBSD port today, it doesn't have the code
that takes the socket as an already open file descriptor at
program startup. So process 50174 actually has two open file
descriptors for the Your Both the System 5 rc scripts and the port-supplied NetBSD rc
script (in
This means that FreeBSD/PC-BSD users can use their conventional
(To make this unit work with systemd too, note that you would
have to explicitly state the invocation of the shell.) Running that through the conversion tool yielded a slightly more
complex service bundle:
This can be manipulated with the It's not necessary to use a full pathname such asJdeBP /tmp $ rcctl get /tmp/lircd JdeBP /tmp $ rcctl set /tmp/lircd device "/run/lirc/lirc0" JdeBP /tmp $ rcctl get /tmp/lircd device=/run/lirc/lirc0 JdeBP /tmp $ sudo rcctl stop /tmp/lircd JdeBP /tmp $ sudo rcctl start /tmp/lircd JdeBP /tmp $ ps -o command -p 50260 COMMAND lircd --nodaemon -d /run/lirc/lirc0 JdeBP /tmp $ /tmp/lircd
. That's only because I chose to operate in /tmp
which isn't a place that is searched for service bundles. I could
have chosen instead to work in /var/local/sv/, in
which case all of the commands above that have /tmp/lircd
would have just read unadorned lircd. As a bonus,
this would have also enabled the system configuration autoconversion
feature of the nosh toolset, which would have taken any lircd_device
setting from /etc/rc.conf{,.local} and applied it to
the lircd service as its device setting
without my having to run rcctl manually.All of this (apart from using the Debian equivalent of FreeBSD's
|