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. (-: