It seems like the lirc package has been converted to be socket activated. Unfortunately that breaks existing installations as lirc.service is replaced by lircd.socket and there is no magic to re-enable things. It's easy enough to fix if you know how things work, but you really shouldn't break working installations in a packet upgrade.
I'm sorry for this, but for better or worse it was deliberate and even stated in the update notes. The root cause is that the package badly needed several fixes which were hard to combine with the old interfaces. Hopefully things works for you now (I presume so from your bug description). Let's leave this bug open for others to discover for some time, but later on I will probably close this bug without further action unless there's more input. Thanks for reporting!
It works fine if you restore the old /usr/lib/systemd/system/lirc.service file from a backup and this file should have been left in place by the update. Changing the interface should be saved for FC20 and one would hope that there might be documentation somewhere. This is a critical package for some people, especially MythTV users.
Does enable the new unit file doesn't work? On my f18/f19 system with a lirc serial adapter i installed the lirc-disable-kernel-rc subpackage and enabled the unit file with systemctl enable lircd.service Everything works well here. [root@mother rave]# systemctl list-unit-files UNIT FILE STATE <snip> lircd.service enabled lircmd.service disabled
If I enable the supplied "lircd.service" file, the daemon does not run. Actually, it looks like it starts up and then something sends it a TERM and it shuts down. I am not sure about that sequence, however. The messages are: Oct 31 15:19:12 localhost systemd[1]: Starting LIRC Infrared Signal Decoder... Oct 31 15:19:12 localhost systemd[1]: Started LIRC Infrared Signal Decoder. Oct 31 15:19:12 localhost lircd-0.9.0[2307]: lircd(atilibusb) ready, using /var/ run/lirc/lircd Oct 31 15:19:12 localhost lircd-0.9.0[2307]: caught signal "lircd" is no longer running after this.
The supplied service file "/usr/lib/systemd/system/lircd.service" seems to be incompatible with the version of "systemd" used with Fedora 19 although the problem may actually be in the way the "--nodaemon" option is implemented in the code. It works with "Type=forking" and the "--nodaemon" option removed. The file "/etc/sysconfig/lirc" must be present and it must explicity define LIRC_DRIVER="DriverName" and LIRC_DEVICE="/dev/lirc0" as these do not default when it is invoked in this way. At least that file is commented. The gratuitous name change of the service file creates confusion and leaves a broken link in /etc/systemd/system/multi-user.target.wants/lirc.service". It certainly would be nice to know how "LIRCD_IR_DEVICE" works. The files are uncommented and a Google search produces only broken links and references indicating that it is an alternative to "lirc-disable-kernel-rc" but no indication of what the values should be.
(In reply to Mike Hughes from comment #5) Hi, thanks for taking time to report! > The supplied service file "/usr/lib/systemd/system/lircd.service" seems to > be incompatible with the version of "systemd" used with Fedora 19 although > the problem may actually be in the way the "--nodaemon" option is > implemented in the code. It works with "Type=forking" and the "--nodaemon" > option removed. Now, we have been testing this on f19 before releasing this update. I don't really think tha f19 is broken per se. That is not to say you aren't hitting a bug. Running with --nodaemon and "Type=simple" should definitely not be broken, though. > The file "/etc/sysconfig/lirc" must be present and it must > explicity define LIRC_DRIVER="DriverName" and LIRC_DEVICE="/dev/lirc0" as > these do not default when it is invoked in this way. At least that file is > commented. Agreed. > > The gratuitous name change of the service file creates confusion and leaves > a broken link in /etc/systemd/system/multi-user.target.wants/lirc.service". As I said, I'm sorry for the breakage. Although it was deliberate, I missed the links becoming stale. This might be fixed in an update (thanks for reporting!) > It certainly would be nice to know how "LIRCD_IR_DEVICE" works. The files > are uncommented and a Google search produces only broken links and > references indicating that it is an alternative to "lirc-disable-kernel-rc" > but no indication of what the values should be. There is actually a rather complete comment in /etc/syscconfig/lirc, with a reference in README.fedora.
(In reply to Alec Leamas from comment #6) As I noted earlier, systemd appears to shut the daemon down after it has been started with the "nodaemon" option. It does not seem like the configuration should make a difference but I am using an ATI-compatible, USB-connected RF control (Snapstream "Firefly") with the "atilibusb" driver. I blacklist the "ati_remote" module to prevent the kernel from seizing it as a keyboard although I have no idea if this is the right way to do it. I know that "atilibusb" is old but it is the only driver which I have been able to make work. I try to maintain the documentation on this remote for the MythTV Wiki so I want to get that updated as soon as possible. Thanks for the tip on LIRCD_IR_DEVICE. I was looking at the old file and did not notice "/etc/sysconfig/lirc.rpmnew". It is not clear if this has any meaning for a USB-connected device.
On one of my mythtv boxes I run a RF remote using the atilubusb driver. As you say, this requires blacklisting ati_remote. Since it's at my home, it's one of the main testcases which always have been working for me (TM). As stated in /etc/sysconfig/lirc, when using an RF remote LIRCD_IR_DEVICE should normally not be set. I leave it as-is i. e., empty. That the daemon shuts down indicates some serious problem. You could run the daemon in a terminal, using the same options as in lircd.service to see what it emits. A look in dmesg after restarting the service might also give a hint. The mechanics: $ sudo systemctl restart lircd.service $ sudo dmesg | tail -20 $ bash $ source /etc/sysconfig/lirc $ sudo /usr/sbin/lircd $LIRCD_OPTIONS --driver $LIRC_DRIVER \ > --device $LIRC_DEVICE --nodaemon
(In reply to Alec Leamas from comment #8) "lircd" runs fine from a terminal: [root@localhost ~]# LIRC_DRIVER="atilibusb" [root@localhost ~]# LIRC_DEVICE="/dev/lirc0" [root@localhost ~]# /usr/sbin/lircd $LIRCD_OPTIONS \ > --driver $LIRC_DRIVER --device $LIRC_DEVICE --nodaemon lircd-0.9.0[4028]: lircd(atilibusb) ready, using /var/run/lirc/lircd lircd-0.9.0[4028]: accepted new client on /var/run/lirc/lircd lircd-0.9.0[4028]: removed client ^Clircd-0.9.0[4028]: caught signal Note the "caught signal" message which occurs when you hit Ctrl-C on the terminal. In comment #4 I listed the messages from "/var/log/messages" when you execute "systemctl start lircd.service" with the original service file. the daemon appears to initialize itself and then emits "caught signal" and stops. I assume the system sent it a TERM. This does not occur if I use "Type=forking" and omit "--nodaemon". With those parameters it works fine. This could certainly be an issue with my particular configuration but it is hard to see what it might be. The OS is a clean install of F19 (64-bit) and up to date. The video configuration is a little weird but I can't see that being an issue in this area. It has both USB2 and USB3 ports and the USB3 is early but the RF receiver is connected to a USB2 port. Thanks for confirming that blacklisting "ati_remote" is the appropriate way to eliminate the pseudo-keyboard function!
(In reply to Mike Hughes from comment #5) > The supplied service file "/usr/lib/systemd/system/lircd.service" ... This might be the source of confusion. You're supposed to enable lircd.socket, not lircd.service. After that lircd will be started on demand, rather than be active all the time.
(In reply to Mike Hughes from comment #9) > (In reply to Alec Leamas from comment #8) > > "lircd" runs fine from a terminal: > > [root@localhost ~]# LIRC_DRIVER="atilibusb" > [root@localhost ~]# LIRC_DEVICE="/dev/lirc0" > [root@localhost ~]# /usr/sbin/lircd $LIRCD_OPTIONS \ > > --driver $LIRC_DRIVER --device $LIRC_DEVICE --nodaemon > lircd-0.9.0[4028]: lircd(atilibusb) ready, using /var/run/lirc/lircd > lircd-0.9.0[4028]: accepted new client on /var/run/lirc/lircd > lircd-0.9.0[4028]: removed client > ^Clircd-0.9.0[4028]: caught signal > > Note the "caught signal" message which occurs when you hit Ctrl-C on the > terminal. In comment #4 I listed the messages from "/var/log/messages" when > you execute "systemctl start lircd.service" with the original service file. > the daemon appears to initialize itself and then emits "caught signal" and > stops. I assume the system sent it a TERM. This does not occur if I use > "Type=forking" and omit "--nodaemon". With those parameters it works fine. Although Pierre's comment on using lircd.socket is correct, it's probably not the root issue here. lircd should run once started anyway. IMHO, chances are high that you have some basic problem that "Type=Forking" just hides rather than actually solving it. BTW, I'd interpret the log messages in comment #4 as if the lircd process crashes rather than e. g., systemd sending it a signal. Hard to be sure, though. If the daemon runs OK in terminal as long as long as you don't give it a ctrl-C it could mean that the instance started by lircd.service is using other options. Have you: - Tested by using "source /etc/sysconfig/lirc" instead of setting LIRC_DRIVER and LIRC_DEVICE manually i. e., doing what systemd does (more or less). - Checked that there is no /etc/systemd/system/lircd.service file overriding the system one (just a double-check, especially for others reading this) - Checked the journalctl output after restarting lircd.service (journalctl -b /usr/sbin/lircd). Once again, just a double-check. - Double-check how lircd is started by systemd: Add to /lib/systemd/system/lircd.service: ExecStartPre=/bin/sh -c 'echo /usr/sbin/lircd $LIRCD_OPTIONS --driver $LIRC_DRIVER --device $LIRC_DEVICE --nodaemon > /tmp/lircd.log' restart the service, check /tmp/lircd.log and run that command in a terminal...
(In reply to Alec Leamas from comment #11) I am glad to know how it is supposed to work and my thanks to Pierre for pointing that out but let me reiterate what he said in his initial report: An update which may be delivered automatically should NEVER, EVER break running systems! It gives the distribution a bad name and should be avoided at all costs, no matter how beautiful the new features are. I would urge in the strongest possible terms that the original "lirc.service" file be restored in an update as soon as possible. It works perfectly well and if users want to check out the new features and alter the configuration to activate them they can do so. It can become the default in Fedora 20 when everyone will be able to work out the configuration before putting the new system into service. The on-demand feature looks a little dubious to me since most softare that uses a remote control will run more or less continuously, often on dedicated hardware. I will continue to look into the issues raised here and report what I find.
Alec, can't you let lircd.socket be enabled by default? Systems that don't use lirc won't see any extra load as there will be nothing triggering lircd to start.
I have actually considered this.I don't find the link (someone, please?) about services enabled by default. But when I did, it required that the service should not need any configuration to be functional if it should be allowed. Obviously, lircd is not so I went for manual enabling. It's far from crystal-clear, though.
(In reply to Alec Leamas from comment #11) Using the new "lircd.service" file but enabling "lircd.socket" works fine although I can't see that it works any differently. The daemon is started during the boot and remains an active process whether anything is connected to it or not. I expected it to shut down when it did not have an active connection. If "lircd.service" is enabled, it does not work. The daemon starts and then shuts down with "caught signal" as the only unexpected message. If the file is changed to "Type=forking" and the "--nodaemon" parameter removed, it works fine. It also works with the old "lirc.service" file which specified "Type=forking". I added a note to the documentation for the "Firefly" remote on the MythTV wiki recommending that the "lirc.service" file be restored and provided the text for paste up if a backup version is not available. I will look at the more general LIRC documentation.
(In reply to Mike Hughes from comment #15) > (In reply to Alec Leamas from comment #11) > > Using the new "lircd.service" file but enabling "lircd.socket" works fine > although I can't see that it works any differently. The daemon is started > during the boot and remains an active process whether anything is connected > to it or not. I expected it to shut down when it did not have an active > connection. The difference is that there has been users having issues when starting e. g., irexec since the introduction of systemd [1]. In random cases irexec was started before lircd, and the socket was not available. Using socket activation ensures that the socket is always available. > If "lircd.service" is enabled, it does not work. The daemon starts and then > shuts down with "caught signal" as the only unexpected message. If the file > is changed to "Type=forking" and the "--nodaemon" parameter removed, it > works fine. It also works with the old "lirc.service" file which specified > "Type=forking". This is on your box. As long as noone else also reports the same thing it might make sense to be a little careful before generalizing this. [1] http://www.mythtv.org/pipermail/mythtv-users/2011-December/324879.html + follow-ups.
(In reply to Alec Leamas from comment #14) > I have actually considered this.I don't find the link (someone, please?) > about services enabled by default. Here: https://fedoraproject.org/wiki/Starting_services_by_default
I have a new update pending. Changelog: - Remove old nowadays stale links to lirc.service. - Fix broken reference to lirc.service in lircmd.service - Update README (troubleshooting) Speak now if you want something else into this update! In particular, if anyone shares Mike's problem not being able to run lircd.service as distributed please let us know.
@mike: Although your problem does not seem to happen to each and everyone, I still smell a bug somewhere (lirc? systemd? docs?). One way to come forward would be to compare my own machine running an RF remote w the atilibusb driver with your, they seem quite similar (?). I attach a script, and my own output from that script. Can you run it and attach your own output? Note that it reinstalls lirc, save any changes you have in /lib/systemd/system/lirc*
Created attachment 823762 [details] test script
Created attachment 823763 [details] My own output.
Created attachment 824715 [details] LIRC test logfile
(In reply to Alec Leamas from comment #19) After running your script, it works fine. Dam you're good! I don't know if the original installation was corrupted or if you got an update in. I think I got a kernel update since I last tested it. I attached the log although it is probably not useful.
After updating today, lircd was not starting for me. I finally tracked it down to missing {} in lircd.service. Without those {} lircd won't start with 'complex' devices. I will attempt to attach a diff. Here is the output of ps when it works: root 659 0.0 0.0 47956 2244 ? Ss 21:01 0:00 /usr/sbin/lircd --permission=666 --driver devinput --device name=Media Center Ed. eHome Infrared Remote Transceiver* --nodaemon
Created attachment 824791 [details] Add {} to env vars
(In reply to John Poet from comment #25) > Created attachment 824791 [details] > Add {} to env vars The {} around env vars is really how systemd works. It does not implement the shell variable expansion syntax, it requires ${variable} to work. The systemd.service manpage has the details.
(In reply to Mike Hughes from comment #23) > (In reply to Alec Leamas from comment #19) > > After running your script, it works fine. Dam you're good! I don't know if > the original installation was corrupted or if you got an update in. There's a small update in updates-testing, but I guess you are not having that repository enabled by default. And it should not affect your problem anyway. > I think > I got a kernel update since I last tested it. I attached the log although > it is probably not useful. Glad that it works for you! You saw the last line in the log and did what it said (...daemon-reload)?
(In reply to Alec Leamas from comment #26) > (In reply to John Poet from comment #25) > > Created attachment 824791 [details] > > Add {} to env vars > > The {} around env vars is really how systemd works. It does not implement > the shell variable expansion syntax, it requires ${variable} to work. The > systemd.service manpage has the details. Ouch, this will require a new update! Sorry for my first reply, it was not really appropriate. I will make a new update asap. Thanks for spotting this! For those of you running into this, a possible walk-around is to install the lirc-disable-kernel-rc which makes the use of these variables unnecessary. Otherwise, I'd recommend to just apply the patch.
lirc-0.9.0-19.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/lirc-0.9.0-19.fc19
lirc-0.9.0-19.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/lirc-0.9.0-19.fc20
We really need to get this update tested and into f19 asap. I would appreciate if you could test this and give some feedback. The mechanics: - # yum --enablerepo=updates-testing update lirc - Use the "Add a comment" link in comment #29 and comment #30 to add a simple Works/"Works not" note.
Adding {} to env vars doesn't work here with my lirc_serial driver. [root@mother rave]# systemctl status -l lircd.service lircd.service - LIRC Infrared Signal Decoder Loaded: loaded (/usr/lib/systemd/system/lircd.service; enabled) Active: active (running) since Sa 2013-11-16 14:02:25 CET; 3s ago Process: 5891 ExecStopPost=/bin/sh -c test -n "${LIRCD_IR_DEVICE}" && echo -lirc > /sys/class/rc/${LIRCD_IR_DEVICE}/protocols || : (code=exited, status=0/SUCCESS) Process: 5893 ExecStartPre=/bin/sh -c test -n "${LIRCD_IR_DEVICE}" && echo lirc > /sys/class/rc/${LIRCD_IR_DEVICE}/protocols || : (code=exited, status=0/SUCCESS) Main PID: 5896 (lircd) CGroup: /system.slice/lircd.service └─5896 /usr/sbin/lircd --driver default --device /dev/lirc0 --nodaemon Nov 16 14:02:25 mother systemd[1]: Started LIRC Infrared Signal Decoder. Nov 16 14:02:25 mother lircd[5896]: lircd-0.9.0[5896]: could not open config file '' Nov 16 14:02:25 mother lircd[5896]: lircd-0.9.0[5896]: No such file or directory Nov 16 14:02:25 mother lircd[5896]: lircd-0.9.0[5896]: lircd(default) ready, using /var/run/lirc/lircd Nov 16 14:02:25 mother lircd-0.9.0[5896]: could not open config file '' Nov 16 14:02:25 mother lircd-0.9.0[5896]: No such file or directory Nov 16 14:02:25 mother lircd-0.9.0[5896]: lircd(default) ready, using /var/run/lirc/lircd Using this exec line in unit file works for me. ExecStart=/usr/sbin/lircd $LIRCD_OPTIONS \ --driver $LIRC_DRIVER --device $LIRC_DEVICE --nodaemon [root@mother rave]# systemctl status -l lircd.service lircd.service - LIRC Infrared Signal Decoder Loaded: loaded (/usr/lib/systemd/system/lircd.service; enabled) Active: active (running) since Sa 2013-11-16 16:26:28 CET; 14s ago Process: 11574 ExecStopPost=/bin/sh -c test -n "${LIRCD_IR_DEVICE}" && echo -lirc > /sys/class/rc/${LIRCD_IR_DEVICE}/protocols || : (code=exited, status=0/SUCCESS) Process: 11592 ExecStartPre=/bin/sh -c test -n "${LIRCD_IR_DEVICE}" && echo lirc > /sys/class/rc/${LIRCD_IR_DEVICE}/protocols || : (code=exited, status=0/SUCCESS) Main PID: 11594 (lircd) CGroup: /system.slice/lircd.service └─11594 /usr/sbin/lircd --driver default --device /dev/lirc0 --nodaemon Nov 16 16:26:28 mother systemd[1]: Starting LIRC Infrared Signal Decoder... Nov 16 16:26:28 mother systemd[1]: Started LIRC Infrared Signal Decoder. Nov 16 16:26:28 mother lircd[11594]: lircd-0.9.0[11594]: lircd(default) ready, using /var/run/lirc/lircd Nov 16 16:26:28 mother lircd-0.9.0[11594]: lircd(default) ready, using /var/run/lirc/lircd
I forgot to mention that lirc-disable-kernel-rc is installed.
(In reply to Wolfgang Ulbrich from comment #33) > I forgot to mention that lirc-disable-kernel-rc is installed. Hm... Have you set LIRCD_IR_DEVICE in /etc/sysconfig/lirc?
(In reply to Alec Leamas from comment #34) > (In reply to Wolfgang Ulbrich from comment #33) > > I forgot to mention that lirc-disable-kernel-rc is installed. > > Hm... Have you set LIRCD_IR_DEVICE in /etc/sysconfig/lirc? No, this was never needed, setting this to "rc0" or "lirc0" doesn't make any different. My lirc device isn't under /sys/class/rc, i have [root@mother rave]# ls /sys/class/lirc/ lirc0 But i'm a bit in doubt that using ${LIRCD_OPTIONS} in exec line is correct, because that isn't a command line option for lircd. [rave@mother ~]$ lircd --help Usage: lircd [options] [config-file] -h --help display this message -v --version display version -n --nodaemon don't fork to background -p --permission=mode file permissions for /var/run/lirc/lircd -H --driver=driver use given driver -d --device=device read from given device -l --listen[=[address:]port] listen for network connections -c --connect=host[:port] connect to remote lircd server -o --output=socket output socket filename -P --pidfile=file daemon pid file -r --release[=suffix] auto-generate release events -a --allow-simulate accept SIMULATE command -u --uinput generate Linux input events -R --repeat-max=limit allow at most this many repeats Imo, LIRCD_OPTIONS should be only set in conf file and the 'lrcd' command reads it. If i use this in unit file ExecStart=/usr/sbin/lircd \ --driver ${LIRC_DRIVER} --device ${LIRC_DEVICE} --nodaemon everything works well.
(In reply to Wolfgang Ulbrich from comment #35) > (In reply to Alec Leamas from comment #34) > > (In reply to Wolfgang Ulbrich from comment #33) > > > I forgot to mention that lirc-disable-kernel-rc is installed. > > > > Hm... Have you set LIRCD_IR_DEVICE in /etc/sysconfig/lirc? > > No, this was never needed, setting this to "rc0" or "lirc0" doesn't make any > different. Hm, that update was not the best I have produced. My testing was void because I had a file in /etc/systemd overriding what I tested, and I missed obvious typos. > > My lirc device isn't under /sys/class/rc, i have > [root@mother rave]# ls /sys/class/lirc/ > lirc0 > > But i'm a bit in doubt that using ${LIRCD_OPTIONS} in exec line is correct, > because that isn't a command line option for lircd. It is. The value of ${LIRCD_OPTIONS} should be valid options, this is documented in /etc/systeconfig/lirc. OTOH, /usr/sbin/lircd is not aware of /etc/sysconfig/lirc in any way. > Imo, LIRCD_OPTIONS should be only set in conf file and the 'lrcd' command > reads it. If i use this in unit file > ExecStart=/usr/sbin/lircd \ > --driver ${LIRC_DRIVER} --device ${LIRC_DEVICE} --nodaemon > > everything works well. See above. I'm about to push a new update fixing a typo + ignoring errors when LIRCD_IR_DEVICE is not set. Now, that one works at least for me. Appreciate if you all could test it. Sorry for the mess.
lirc-0.9.0-20.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/lirc-0.9.0-20.fc19
lirc-0.9.0-20.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/lirc-0.9.0-20.fc20
Now, running on all my machines. There was yet another problem when LIRCD_OPTIONS is blank: systemd expands it to '', not just space. Adding a sh wrapper to handle this, another update under way(!). Hopefully, this should be testable (sigh).
lirc-0.9.0-21.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/lirc-0.9.0-21.fc19
lirc-0.9.0-21.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/lirc-0.9.0-21.fc20
The last update is tested by Wolfgang (thanks!), so there's one positive karma vote. If possible, please test the update in comment #40 so we can push it asap.
lirc-0.9.0-21.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
We still need a vote for the f19 update, link in comment #40. If someone could test and provide some simple works/works not feedback it would make things much easier...
lirc-0.9.0-21.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
There has been no more input on this for some time and f20 is released. Closing bug, please feel free to reopen if need be.