Bug 1025030 - upgrade disables lircd
upgrade disables lircd
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: lirc (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Alec Leamas
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-30 15:06 EDT by Pierre Ossman
Modified: 2014-01-04 05:16 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-04 05:16:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test script (372 bytes, text/plain)
2013-11-14 01:07 EST, Alec Leamas
no flags Details
My own output. (11.42 KB, text/plain)
2013-11-14 01:07 EST, Alec Leamas
no flags Details
LIRC test logfile (7.48 KB, text/plain)
2013-11-15 16:24 EST, Mike Hughes
no flags Details
Add {} to env vars (969 bytes, patch)
2013-11-15 23:08 EST, John Poet
no flags Details | Diff

  None (edit)
Description Pierre Ossman 2013-10-30 15:06:00 EDT
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.
Comment 1 Alec Leamas 2013-10-30 15:30:45 EDT
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!
Comment 2 Mike Hughes 2013-11-01 17:07:25 EDT
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.
Comment 3 Wolfgang Ulbrich 2013-11-01 17:23:59 EDT
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
Comment 4 Mike Hughes 2013-11-01 18:45:07 EDT
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.
Comment 5 Mike Hughes 2013-11-06 08:44:51 EST
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.
Comment 6 Alec Leamas 2013-11-06 09:05:08 EST
(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.
Comment 7 Mike Hughes 2013-11-06 13:14:39 EST
(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.
Comment 8 Alec Leamas 2013-11-06 13:58:02 EST
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
Comment 9 Mike Hughes 2013-11-06 16:09:42 EST
(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!
Comment 10 Pierre Ossman 2013-11-07 00:52:18 EST
(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.
Comment 11 Alec Leamas 2013-11-07 06:48:37 EST
(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...
Comment 12 Mike Hughes 2013-11-07 09:39:01 EST
(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.
Comment 13 Pierre Ossman 2013-11-07 11:25:44 EST
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.
Comment 14 Alec Leamas 2013-11-07 12:03:22 EST
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.
Comment 15 Mike Hughes 2013-11-08 15:44:21 EST
(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.
Comment 16 Alec Leamas 2013-11-09 03:23:53 EST
(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.
Comment 17 Alec Leamas 2013-11-09 03:45:04 EST
(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
Comment 18 Alec Leamas 2013-11-11 04:29:50 EST
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.
Comment 19 Alec Leamas 2013-11-14 01:06:05 EST
@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*
Comment 20 Alec Leamas 2013-11-14 01:07:04 EST
Created attachment 823762 [details]
test script
Comment 21 Alec Leamas 2013-11-14 01:07:52 EST
Created attachment 823763 [details]
My own output.
Comment 22 Mike Hughes 2013-11-15 16:24:00 EST
Created attachment 824715 [details]
LIRC test logfile
Comment 23 Mike Hughes 2013-11-15 16:29:16 EST
(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.
Comment 24 John Poet 2013-11-15 23:07:45 EST
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
Comment 25 John Poet 2013-11-15 23:08:42 EST
Created attachment 824791 [details]
Add {} to env vars
Comment 26 Alec Leamas 2013-11-15 23:49:11 EST
(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.
Comment 27 Alec Leamas 2013-11-15 23:56:02 EST
(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)?
Comment 28 Alec Leamas 2013-11-16 00:05:13 EST
(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.
Comment 29 Fedora Update System 2013-11-16 00:44:27 EST
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
Comment 30 Fedora Update System 2013-11-16 00:47:12 EST
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
Comment 31 Alec Leamas 2013-11-16 01:02:54 EST
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.
Comment 32 Wolfgang Ulbrich 2013-11-16 10:29:04 EST
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
Comment 33 Wolfgang Ulbrich 2013-11-16 10:33:08 EST
I forgot to mention that lirc-disable-kernel-rc is installed.
Comment 34 Alec Leamas 2013-11-16 11:15:19 EST
(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?
Comment 35 Wolfgang Ulbrich 2013-11-16 11:40:13 EST
(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.
Comment 36 Alec Leamas 2013-11-16 22:42:42 EST
(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.
Comment 37 Fedora Update System 2013-11-16 23:07:54 EST
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
Comment 38 Fedora Update System 2013-11-16 23:09:06 EST
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
Comment 39 Alec Leamas 2013-11-16 23:45:19 EST
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).
Comment 40 Fedora Update System 2013-11-16 23:49:25 EST
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
Comment 41 Fedora Update System 2013-11-16 23:56:53 EST
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
Comment 42 Alec Leamas 2013-11-17 10:27:02 EST
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.
Comment 43 Fedora Update System 2013-11-19 16:49:44 EST
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.
Comment 44 Alec Leamas 2013-11-19 17:39:05 EST
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...
Comment 45 Fedora Update System 2013-12-03 05:30:27 EST
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.
Comment 46 Alec Leamas 2014-01-04 05:16:58 EST
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.

Note You need to log in before you can comment on or make changes to this bug.