Jonathan de Boyne Pollard:
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 |/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, however. [...]
Alec Leamas:
Now, the systemd scripts are the upstream ones, and they are used in
several distributions. Hence, statements like "they are wrong" in the
sense that services doesn't start should be taken with some grain of
salt. In this case, it seems like the nosh utility doesn't use the
systemd tmfiles.d mechanisms which is the way to create temporary
files and directories in the systemd world.
I'd have used that if I'd found one. I looked, as that's the other way
of doing this instead of the |RuntimeDirectory| setting. There's *is
no* tmpfiles snippet in your source tree, that I could find. Your
|/systemd/| subdirectory (at
http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/) contains only
unit files, notice; and there's nothing elsewhere that I could find.
So yes: your service unit files are wrong, or your source tree that you
give to the world is incomplete. You don't provide complete
configuration for a functional system.
Also note that Lennart Poettering would like you to use
|RuntimeDirectory| for this in preference to tmpfiles snippets, and have
your program do that in preference to either, since you are configuring
it to run as the superuser. So there's an argument, at least from the
systemd people, that /your daemon//program/ is incomplete.
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012024.html
I did enjoy the Mouse Trap nature of your lircd-setup service, that I
looked at when looking for where you could be hiding your creation of
the |/run/lirc/| directory. Your lircd service unit pulls in another
oneshot service unit that in turn invokes a Python program
(http://sourceforge.net/p/lirc/git/ci/master/tree/tools/lircd-setup),
which then reads a configuration file for a string, that it in turn
passes to the POSIX-compatible shell for execution as an arbitrary shell
command (with superuser privileges, of course). There's definitely a
middle man to be cut out, there. Learn from the mistakes in the systemd
House of Horror. (-:
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/systemd-house-of-horror/
Alec Leamas:
That said, I have sent a question to Stefan about his role here: is
the maintainer? If so, what is his plans? However, I still havn't got
any reply on this.
You can actually look the answer to the first question up for yourself:
https://packages.debian.org/source/sid/lirc
That's how I knew that xe was one of the maintainers. (-:
