On 17/01/16 03:23, Jonathan de Boyne Pollard wrote:
> 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.
>
> http://anonscm.debian.org/viewvc/pkg-lirc?view=revision&revision=521
>
> 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. (-:
OK, here is two things both covered in my reply in original thread:
- Stefan's role. A statement from him on this would be good.
- We should incorporate reasonable sysV patches including those in
current svn tree in upcoming update, agreed.
> 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 |lircd.socket| and
> |lircd.service| unit files through the nosh conversion process and
> seeing what resulted. Your "bad gut feeling" about your System 5 rc
> files is, ironically, misplaced and should be about your systemd
mechanisms.
There is certainly two possibilities here: that the systemd scripts are
wrong, or that the nosh utility fails. I presume that if the scripts
actually works in the sense that they start the services (which they do)
we need to take a look at nosh, right?
> Yes the nosh package can take this sort of thing
[snip]
> 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.
No, it's because nosh fails.
> A quick check of the log revealed that the service was trying to create
> a local-domain socket at |/run/lirc/lircd| . But there was no
> |/run/lirc/| directory on my system to contain that. Your systemd units
> didn't make one; and one doesn't appear by telepathy. (-: Stefan
> Lippers-Hollmann's System 5 rc scripts *do* make this directory,
As I stated in previous reply, temporary files are created using the
tmpfiles.d mechanism (where the .service/.socket files isn't involved in
any way).
[upstream hat on] If it would make things easier, we could of course use
other mechanisms as long as they works if it makes nosh's task easier.
Patches (upstream!) welcome!
> however. They have this near the start:
>
> [ -d "/run/lirc" ] || mkdir -p "/run/lirc"
>
> The systemd service unit file way of doing the same thing is:
>
> [Service]
> RuntimeDirectory=lirc
Well, it's a possibility. However, the lirc packaging uses tmpfiles.d.
> So I edited that into your |lircd.service| and had another go. This
> time I was hit by a problem with "quirks mode" conversion (which I don't
> use all that often). Since your |lircd| program doesn't actually rely
> upon any systemd quirks as far as I can see, I simply switched to "ideal
> mode" conversion and converted a third time:
>
> JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket
> JdeBP /tmp $ sudo system-control start /tmp/lircd
Sorry, I don't follow you here. What are these quirks, is it something
to be used, and then why?
> Now I was hit by the fact that you'd hardwired the pathname
> |/usr/sbin/lircd| into your service unit. This isn't wrong from a Linux
> systemd operating system perspective. But I'm doing this on FreeBSD
> (PC-BSD 10.2, in fact) to demonstrate that the nosh toolset very much
> does provide the tools for non-Linux operating systems. The
> FreeBSD-supplied lircd installs into |/usr/local/sbin |not |/usr/sbin|,
> because that's the rule for non-operating-system stuff. Fortunately,
> there are at least two ways around this. I took the one that uses
> |$PATH|. The conversion tool can be told |ExecStart=lircd| and that will
> make a service bundle that will just work for either |/usr/sbin/lircd|
> or |/usr/local/sbin/lircd| . So I edited that into your |lircd.service|
OK. Isn't this just one of those things we do from time to time when
packaging stuff?
[upstream hat on] I'd certainly accept a patch, e. g., letting autotools
define the path in the service file.
> and had another go.
>
> 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.
Which is great. If nosh somehow could handle also the tmpfiles stuff all
that is needed is fixing some installation paths, which is normal
packaging efforts.
> 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
That code is since 2011, so...
> file descriptor at program startup. So process 50174 actually has two
> open file descriptors for the |/run/lirc/lircd| socket, one that was set
> up for it with UCSPI-TCP and one that it opened itself because the
> FreeBSD port doesn't actually contain any |HAVE_SYSTEMD| code.
>
> Your |HAVE_SYSTEMD| approach isn't ideal, from your perspective of
> having lircd work on other operating systems like it does with systemd,
It's certainly not 'my', it's upstream systemd stuff.
> This is because it doesn't cope with non-Linux operating
> systems where you might still get the listening socket passed in,
> already open. This is in turn because you are using the systemd
> developers' library. Their library doesn't do anything on non-Linux
> operating systems. I recommend instead looking to one of the many
> alternatives now available and floating around on the likes of GitHub.
> The alternatives don't conditionally compile out everything on non-Linux
> targets.
>
> Both the System 5 rc scripts and the port-supplied NetBSD rc script (in
> |/usr/local/etc/rc.d/lircd|) are parameterized. Your systemd unit files
> are not. In particular, note that the NetBSD rc script has this:
>
> command_args="-d ${lircd_device} ${lircd_config}"
>
> This means that FreeBSD/PC-BSD users can use their conventional
> |/etc/rc.conf.local| system to configure how the lircd daemon is
> invoked, by setting |lircd_device| and |lircd_config| variables. (See
> the rc.conf(5) manual page for details of this system.) There's even a
> handy |rcctl| tool in OpenBSD designed for working with these settings.
> This mechanism can be made to work with the nosh toolset. I adjusted
> your |lircd.service| yet again to now read:
>
> EnvironmentDirectory=env
> ExecStart=lircd --nodaemon ${device:+-d "${device}"} ${config}
>
> (To make this unit work with systemd too, note that you would have to
> explicitly state the invocation of the shell.)
If you provide patches for this they certainly should be considered.
However, note the new lirc_options.conf file which should be used for
these purposes. Please also note the "Environment files considered
harmful" debate.
> Running that through the conversion tool yielded a slightly more complex
> service bundle:
>
> JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket
> JdeBP /tmp $ mkdir /tmp/lircd/service/env
> JdeBP /tmp $ cat /tmp/lircd/service/service
> #!/bin/nosh
> #Service file generated from ./lircd.service
> #LIRC Infrared Signal Decoder
> sh -c "exec lircd --nodaemon ${device:+-d \"${device}\"} ${config}"
> JdeBP /tmp $
>
> This can be manipulated with the |rcctl| shim provided in the nosh
toolset:
>
> JdeBP /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 $
>
> It's not necessary to use a full pathname such as |/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 |fetch|
> command) is pretty much exactly the same on Debian, when nosh-managed.
> I went through much the same steps.
Now, doesn't this really boil down to something like "Upcoming lirc
systemd scripts cannot be converted by nosh" ? And that this partly is
about nosh, and partly about (upcoming) lirc?
The easy part is of course that reasonable patches for this should be
accepted. (Note the "Environment files considered harmful" debate here.)
Bottom line is, however, if this is a requirement Debian has on systemd
packaging?
Cheers!
--alec
