#156 Provide service file for irexec

[T. Chelovek]

While setting up irexec as service, I found the appropriate service file to be missing.

Creating my own worked, but only when started manually, not after boot

I found a working solution at https://bbs.archlinux.de/viewtopic.php?id=28151

I now use /etc/systemd/system/lircd.service

[Unit]
Description=LIRC Infrared Signal Decoder
After=network.target

[Service]
Type=forking
ExecStart=/usr/sbin/lircd --pidfile=/var/run/lirc/lircd.pid
PIDFile=/var/run/lirc/lircd.pid

[Install]
WantedBy=multi-user.target

and /etc/systemd/system/irexecd.service

[Unit]
Description=IR Exec
After=lircd.service
Requires=lircd.service

[Service]
Type=forking
ExecStart=/usr/sbin/irexec --daemon

[Install]
WantedBy=multi-user.target

While this may not be perfect, it works nicely and would probably help people save some time if added to the tarball

[Alec Leamas]

Hm... the recommended way so far is to run irexec as part of the session, using the autostart file available in contrib. Why do you want to run irexec as a system daemon? You have found [1], have you?

And even if you want to run it as a system daemon, why complicate things with a forking service?

[1] http://lirc.sourceforge.net/lirc.org/html/configuration-guide.html#appendix-7

EDIT: also, the After directive is not required. lird supports socket activation, so the socket is there before any service is started.

[T. Chelovek]

As I said "Creating my own worked, but only when started manually, not after boot"

Looking for a solution I found this example, which works as I wanted.

I am running irexec presently as system service, because I am controlling system functions on a headless SBC with it. Like starting / stopping services, shutdown and the like.

I am not a systemd specialist, so if anything can be refined, it's fine with me.

At least one person had this problem too, the one I copied the solution from.

[Alec Leamas]

First: the lircd service file is plain wrong. However, the package installs proper files (lircd.socket + lircd.service) in system location /bin/systemd/system (the sources are in the systemd/ library). So, basically lircd should be fine just you remove the /etc variant.

For the irexec system service I see your point. It might make sense to include a service file for this usecase - perhaps even as a default service. Will think about it. Needs some docs as well.

[T. Chelovek]

I should have mentioned, that ARCHLinux Arm packaging somewhat changes the install locations.

So /bin/systemd/system plainly does not exist. The ARCH package puts the package provided files into

/usr/lib/systemd/system

If changes are needed the suggestion ist to use files in

/etc/systemd/system

which will override any files provided by package in /usr/lib/systemd/systemand makes sure they don't get overwritten by pacman on package updates.

The relevant line from PKGBUILD reads

  ./configure --prefix=/usr --sbindir=/usr/bin --sysconfdir=/etc --localstatedir=/var \
          --with-transmitter --enable-sandboxed

The /bin and /sbin directories are just links to /usr/bin

ls -l /bin /sbin
lrwxrwxrwx 1 root root 7 Oct  5 21:06 /bin -> usr/bin
lrwxrwxrwx 1 root root 7 Oct  5 21:06 /sbin -> usr/bin

unmae -rm says

3.10.80-15-ARCH armv7l

[Alec Leamas]

I should have mentioned, that ARCHLinux Arm packaging somewhat changes the install locations.

So /bin/systemd/system plainly does not exist.

My bad, typo, sort of. It's not /bin/systemd/system, it's (obviously) /lib/systemd/system. This path is a hardcoded systemd thing, so Arch havn't changed it.

If changes are needed the suggestion ist to use files in /etc/systemd/system

This is just systemd, how it works.

Anyway, you should IMHO remove your /etc/systemd/system/lircd.service file and use the provided. They are in /lib/systemd/system unless the installation is a complete mess. You can use systemctl status lircd.socket to get the initial state etc.

[T. Chelovek]

As I am using lirc from an ARCH Linux Arm repository, the result is hardly "a mess". Packagers use to change installation paths to their liking, which I'm not going to argue.

Since /usr/lib/systemd/system gets overwritten when upgrading the package, the suggestion of people who are wiser than I am, is to place any personally fabricated stuff in /etc/systemd/system where systemd finds it and uses it instead of the package provided files.

As my setup presently works as intended, while the provided service file does not, I don't think I will change anything for cosmetics. Any suggestions improving the solution I found functionally is certainly welcome..

[Alec Leamas]

Had to check.. yes, Arch stores vendor service files in /lib/systemd/system. It also has this symlink /lib -> /usr/lib which makes /lib/systemd and /usr/lib/systemd the same location. They have not changed any installation paths here, and honestly I don't think it's technically possible - systemd is by no mean a normal package.

Besides that, I'm of course curious what the problem was with the original lircd.service file which forced you to write your own. In other words, I'd appreciate a ticket for whatever problem there is. If you file one, please attach the service file in case the packagers have patched it.

If you still want to use your own /etc file, I suggest that you make the service "simple" remove the pidfile option and adds --nodaemon - it's actually more robust. Same goes for irexec (remove the --daemon option), for which you might also consider a 'restart' directive. You have the lircd source in systemd.

Not using the lircd.socket unit might lead to subtle (race) boot problems. You have that enabled, have you?

[T. Chelovek]

Besides that, I'm of course curious what the problem was with the original lircd.service
file which forced you to write your own.

As stated in the first post:
"Creating my own worked, but only when started manually, not after boot"

So nothing is wrong with yourlircd.service as long as no irexecd.service is establishing a system service depending on it.

Creating an irexecd.service after lircd.service works, but only if started manually, i.e. from a session when everything runs already.

When booting, irexecd.service would fail, indicating that there is a race condition between lircd and irexecd. I tried various forms of Requires= and After= but only got the example I linked to to work. (incidentally Arch Linux with Arch repo supplied lirc)

My guess is, that systemd fails to detect lircd is running if it is not Type=forking and ponting to its PID file.

As also pointed out earlier I'm not a systemd, not even a Linux wizard, so, as far as I am concerned, the solution does what I want, but may not qualify for a distributable, hence the ticket.

[Alec Leamas]

Creating an irexecd.service after lircd.service works, but only if started
manually, i.e. from a session when everything runs already.

This should not happen if you have lircd.socket enabled - it's the very reason it exists. Using this unit, systemd creates the socket before any service is started, so there will be no race condition (I know, this is hairy stuff).

My guess is, that systemd fails to detect lircd is running if it is not
Type=forking and ponting to its PID file.

systemd does not miss to detect lircd without a pid file as long as it runs with --nodaemon, no way. This is the preferred setup where systemd has better control over the running process. The combination of a "forked" service, pidfile and no '--nodaemon' is more or less a hack to stay compatible with old code. If possible (and for lircd it's definitely possible) stay away from it.

I'm rather convinced here is some other problem lurking around. Your lircd.service file should not solve any problem, but might introduce some new.

[T. Chelovek]

Well Alec, you sound very convincing, so if we stick to your lircd.service, how do we get irexecd.service to function on boot ?

Your'e the Guru, ain't you ? ;-)

[Alec Leamas]

No guru... :( But enable the lircd.socket unit, that should be it (systemctl enable lircd.-socket; systemctl start lircd.socket)

[T. Chelovek]

Now, then, I removed/etc/systemd/system/lircd.service, which, in effect, puts back the package provided file into service, enabled lircd.socket and rephrased
/etc/systemd/system/irexecd.service to

[Unit]
Description=LIRC Infrared Signal Exec

[Service]
Type=simple
ExecStart=/usr/sbin/irexec

[Install]
WantedBy=multi-user.target

and it seems to do what I want. Reboot and all.

Now one thing leaves me scratching my head: Why did everythin run fine without lircd.socket being enabled ? And why, if it is needed doesn't it get enabled by the installation process ?

[Alec Leamas]

That service file looks good. As I said, you might consider the 'restart' directive if need be

Now one thing leaves me scratching my head: Why did everythin run
fine without lircd.socket being enabled

The role of lircd.socket is subtle, but is basically about avoiding a race condition. If you google 'systemd socket activation' you should get the picture. lircd has code to use the socket systemd handles to it (you might need some reading to understand this). But it's not surprising that it mostly works without the socket, no.

And why, if it is needed doesn't it get enabled by the installation process ?

The short answer is that this is a packaging issue. The somewhat longer answer is that systemd uses installation-wide service presets for these kind of settings. Most distros, (ubuntu might be an exception) hesitate to start services behind the back of admins.

[Alec Leamas]

Fixed in [7aebfc] where we not just add a service file but a complete service ready to be started after installation.