[mythtv-users] Upgraded to Fedora 22 and lirc is misbehaving

Jerry mythtv at hambone.e4ward.com
Wed May 27 01:19:32 UTC 2015


On Tue, May 26, 2015 at 8:40 PM, Hika van den Hoven <hikavdh at gmail.com>
wrote:

> Hoi Jerry,
>
> Wednesday, May 27, 2015, 2:41:20 AM, you wrote:
>
> > On Tue, May 26, 2015 at 7:19 PM, Hika van den Hoven <hikavdh at gmail.com>
> > wrote:
>
> >> Hoi Hika,
> >>
> >> Wednesday, May 27, 2015, 12:57:59 AM, you wrote:
> >>
> >> > Hoi Jerry,
> >>
> >> > Wednesday, May 27, 2015, 12:51:01 AM, you wrote:
> >>
> >> >> I have not changed a thing except for adding this non-working udev
> rule.
> >> >> Everything worked fine until this afternoon.
> >>
> >> >> Other than that, every service seems to be working on the new
> install.
> >> I'm
> >> >> watching comedy central on live tv at the moment.  I had a bit of an
> >> issue
> >> >> with rpmfusion's nVidia drivers (no 22 rpms for the new kernel) but I
> >> >> solved that by installing the Fedora 21 akmod-nvidia-340xx rpms, in
> case
> >> >> anyone else has issues.  I should have switched to akmod a long time
> >> ago.
> >>
> >> >> Ok, on to lirc:
> >>
> >> >> [root at htpc ~]# ls -l /dev/lirc0
> >> >> crw------- 1 root root 246, 0 May 26 18:17 /dev/lirc0
> >> >> [root at htpc ~]# more /etc/udev/rules.d/10-lirc.rules
> >> >> KERNEL=="lirc0", NAME=="lirc0", GROUP="root", MODE=="0777"
> >> >> [root at htpc ~]#
> >>
> >> >> If I change the permissions of /dev/lirc0 to 777, everything works.
> I'd
> >> >> rather not do that, but I will for now just temporarily.
> >>
> >> >> If I start it up without changing the permissions, this shows up in
> the
> >> log:
> >>
> >> >> May 26 18:28:58 htpc systemd: Started LIRC Infrared Signal Decoder.
> >> >> May 26 18:28:58 htpc systemd: Starting LIRC Infrared Signal
> Decoder...
> >> >> May 26 18:28:58 htpc audit: <audit-1130> pid=1 uid=0 auid=4294967295
> >> >> ses=4294967295 msg='unit=lircd comm="systemd"
> >> >> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> res=success'
> >> >> May 26 18:28:58 htpc lircd: lircd-0.9.2a[2199]: Notice: Running as
> user
> >> lirc
> >> >> May 26 18:28:58 htpc lircd-0.9.2a[2199]: Notice: Running as user lirc
> >> >> May 26 18:28:58 htpc lircd: lircd-0.9.2a[2199]: Info: Using remote:
> >> mceusb.
> >> >> May 26 18:28:58 htpc lircd-0.9.2a[2199]: Info: Using remote: mceusb.
> >> >> May 26 18:28:58 htpc lircd: lircd-0.9.2a[2199]: Notice:
> lircd(default)
> >> >> ready, using /var/run/lirc/lircd
> >> >> May 26 18:28:58 htpc lircd-0.9.2a[2199]: Notice: lircd(default)
> ready,
> >> >> using /var/run/lirc/lircd
> >> >> May 26 18:28:59 htpc lircd: lircd-0.9.2a[2199]: Notice: accepted new
> >> client
> >> >> on /var/run/lirc/lircd
> >> >> May 26 18:28:59 htpc lircd-0.9.2a[2199]: Notice: accepted new client
> on
> >> >> /var/run/lirc/lircd
> >> >> May 26 18:28:59 htpc lircd-0.9.2a[2199]: Error: could not open
> >> /dev/lirc0
> >> >> May 26 18:28:59 htpc lircd-0.9.2a[2199]: default_init(): Permission
> >> denied
> >> >> May 26 18:28:59 htpc lircd-0.9.2a[2199]: Warning: Failed to
> initialize
> >> >> hardware
> >> >> May 26 18:28:59 htpc lircd: lircd-0.9.2a[2199]: Error: could not open
> >> >> /dev/lirc0
> >> >> May 26 18:28:59 htpc lircd: lircd-0.9.2a[2199]: default_init():
> >> Permission
> >> >> denied
> >> >> May 26 18:28:59 htpc lircd: lircd-0.9.2a[2199]: Warning: Failed to
> >> >> initialize hardware
> >> >> May 26 18:29:00 htpc lircd: lircd-0.9.2a[2199]: Error: could not open
> >> >> /dev/lirc0
> >> >> May 26 18:29:00 htpc lircd: lircd-0.9.2a[2199]: default_init():
> >> Permission
> >> >> denied
> >> >> May 26 18:29:00 htpc lircd-0.9.2a[2199]: Error: could not open
> >> /dev/lirc0
> >> >> May 26 18:29:00 htpc lircd-0.9.2a[2199]: default_init(): Permission
> >> denied
> >> >> May 26 18:29:01 htpc lircd: lircd-0.9.2a[2199]: Error: could not open
> >> >> /dev/lirc0
> >> >> May 26 18:29:01 htpc lircd: lircd-0.9.2a[2199]: default_init():
> >> Permission
> >> >> denied
> >> >> May 26 18:29:01 htpc lircd-0.9.2a[2199]: Error: could not open
> >> /dev/lirc0
> >> >> May 26 18:29:01 htpc lircd-0.9.2a[2199]: default_init(): Permission
> >> denied
> >> >> May 26 18:29:02 htpc lircd: lircd-0.9.2a[2199]: Error: could not open
> >> >> /dev/lirc0
> >> >> May 26 18:29:02 htpc lircd-0.9.2a[2199]: Error: could not open
> >> /dev/lirc0
> >> >> May 26 18:29:02 htpc lircd-0.9.2a[2199]: default_init(): Permission
> >> denied
> >>
> >> >> ...and it goes on and on.
> >>
> >> >> Is it possible for me to make a working udev rule for /dev/lirc0?
> What
> >> >> should the permissions be?
> >> >> I tried changing the group to lirc and setting the permissions
> >>
> >> >> [root at htpc ~]# ps aux | grep lirc
> >> >> lirc      2199  0.0  0.0  57956  3836 ?        Ss   18:28   0:00
> >> >> /usr/sbin/lircd --nodaemon
> >> >> root     14117  0.0  0.0 114328  2304 pts/0    R+   18:33   0:00 grep
> >> >> --color=auto lirc
> >> >> [root at htpc ~]#
> >>
> >> >> I tried changing the group to lirc and changing permissions to 770
> but
> >> that
> >> >> failed.
> >>
> >> >> Since it's stuck on an initialization loop until the device allows
> >> >> permission, I am going to add a line in /etc/rc.d/rc.local:
> >>
> >> >> chmod 777 /dev/lirc0
> >>
> >> >> This seems like an awful hack.  Does anyone have a better idea?
> >>
> >> >> Thanks!
> >> >> Jerry
> >>
> >> > It says it is running as user lirc! and the original permission is
> >> > only rw to root. So either change ownership to user lirc or to the
> >> > group lirc is in and changing permissions to 660. (no x flag needed)
> >> > So if that group is also lirc:
> >>
> >> >> KERNEL=="lirc0", NAME=="lirc0", GROUP="lirc", MODE=="0660"
> >>
> >> > Or run the service as root
> >>
> >> Sorry I missed that you tried changing permission, but that it failed.
> >> What failed? The changing permission or like before? Dit you verify
> >> that user lirc has/is in group lirc?
> >>
> >> I have it running as root, which is normal for such a basic service.
> >>
> >>
> > After a reboot, the permissions on /dev/lirc0 did not change.  Shouldn't
> > the device have been changed?  Is lircd creating the device afterward or
> > before the udev rule does?  I have two other rules in that directory.
>
> > [root at htpc ~]# more /etc/udev/rules.d/10-lirc.rules
> > KERNEL=="lirc0", NAME=="lirc0", GROUP="lirc", MODE=="0660"
> > [root at sirius ~]# ls -l /dev/lirc0
> > crw------- 1 root root 246, 0 May 26 20:28 /dev/lirc0
> > [root at htpc ~]#
>
> > [root at htpc ~]# ls -l /etc/udev/rules.d/
> > total 12
> > -rw-r--r--  1 root root  59 May 26 20:25 10-lirc.rules
> > -rw-r--r--. 1 root root 104 Sep 18  2013 81-remote-control-lirc.rules
> > -rw-r--r--  1 root root  68 Mar 10 19:56 85-rtc.rules
> > [root at htpc ~]# more /etc/udev/rules.d/81-remote-control-lirc.rules
> > SUBSYSTEM=="rc", ATTRS{protocols}=="*lirc*" RUN+="/bin/sh -c 'echo lirc >
> > /sys$env{DEVPATH}/protocols'"
> > [root at sirius ~]# more /etc/udev/rules.d/85-rtc.rules
> > KERNEL=="rtc0", ATTR{name}=="rtc_cmos", GROUP="mythtv", MODE="0660"
> > [root at htpc ~]#
>
> > If I change the ownership to root:lirc and chmod 660, lircd still
> complains
> > as above.   If I chmod 666 /dev/lirc0, everything works!  Why is that?
> Why
> > does it need "other" permissions?  The process is owned by lirc.  I
> think.
>
> > Anyway, for now I just added a line to devil sign (chmod 666) the device
> in
> > rc.local.  It works, but it just feels wrong.
>
> > Thanks!
> > Jerry
>
>
> /dev/lirc0 is created by udev. /dev/lircd (or /var/run/lirc/lircd) by
> lircd.
>
> I notice that the serial on your lirc.rules is very low. They are
> processed in that order. It should be at least in the 60, so make it
> 80
> mv /etc/udev/rules.d/10-lirc.rules /etc/udev/rules.d/80-lirc.rules
>
> What is the ownership of /var/run/lirc/lircd? Try to mimic that
> ownership.
>
>
I changed it to 80-lirc.rules and put 0666 as the MODE
[root at htpc rules.d]# ls -l /var/run/lirc/lircd
srw-rw-rw- 1 root root 0 May 26 20:43 /var/run/lirc/lircd
[root at htpc rules.d]#

after a reboot:

[syn4pse at htpc ~]$ ls -l /dev/lirc0
crw------- 1 root root 246, 0 May 26 21:13 /dev/lirc0
[syn4pse at htpc ~]$

It does not seem to be responding for some reason.

Thanks for your help, Hika.  I have to take a break until tomorrow but I'll
be ready to try something else in the morning. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20150526/86fbb159/attachment.html>


More information about the mythtv-users mailing list