Posts: 5
Joined: Tue Jul 16, 2013 4:58 am

lirc has to be manually retarted after boot

Mon Aug 05, 2013 3:55 pm

So I got lirc working, both for receive and for transmit, and it's pretty reliable.

But... every time I reboot, lirc does not work, irsend gives a timeout and irw does not show anything when IR buttons are pressed, basically nothing do do with infra-red works after a reboot.

But if, after boot, I login to the pi and do "sudo /etc/init.d/lirc restart" (which, looking at the script, calls itself with "stop" and then "start"), it all works perfectly.

`runlevel` reports "N 2", and /etc/rc2.d contains a symbolic link:
S16lirc -> ../init.d/lirc

I cannot find anything helpful in the logs (under /var/log, grepping for "lirc") which shows anything going wrong on boot, but evidently it is!

As a *hack* I tried adding a line in /etc/rc.local before the "exit 0" as follows:
"/etc/init.d/lirc restart"
but it did not help.

I then tried this instead
"sudo /etc/init.d/lirc restart"
and it worked (I rebooted twice and each time there was no need to manually restart).

So naturally, my first questions are:
Why do I need the "sudo" here?
Which user/group id are the /etc/rc2.d SxxCommand links run as? Presumably not root.
What permissions do I need to tweak or chmod do I need to change, so that I can remove the horrible hack?

Sorry if this is off-topic, since it may be more of a general Linux/Debian question.
I posted it here because it is spoiling my automation/sensing user-experience on my Raspberry Pi! ;-)

Posts: 1
Joined: Sun Aug 11, 2013 1:40 pm

Re: lirc has to be manually retarted after boot

Sun Aug 11, 2013 1:42 pm

I have the same problem (using raspbmc), and have to use the same hack. Very interested in a better solution for this...

Posts: 15
Joined: Fri Oct 11, 2013 7:08 pm

Re: lirc has to be manually retarted after boot

Fri Oct 11, 2013 7:22 pm

same issue on 10/2013 raspbmc, but I additionally had to delay the restart in /etc/rc.local:

Code: Select all

(sleep 5 && sudo /etc/init.d/lirc restart) &
Is the fact that input device 1 from initial start is mapped before the receiver is detected the root-cause of all this mess?

[email protected]:~$ dmesg | grep lirc
lirc_dev: IR Remote Control driver registered, major 250
lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
lirc_rpi lirc_rpi.0: lirc_dev: driver lirc_rpi registered at minor = 0
lirc_rpi: driver registered!
input: lircd as /devices/virtual/input/input1
lirc_rpi: auto-detected active low receiver on GPIO pin 18
input: lircd as /devices/virtual/input/input2


Posts: 5
Joined: Fri Feb 06, 2015 12:27 pm

Re: lirc has to be manually retarted after boot

Fri Feb 06, 2015 12:33 pm

I add the line at /etc/rc.local but nothing happends.
It is a problem with the /etc/rc.local, any ideas why doesn't execute at boot?
The file has permission of execution.

Posts: 1
Joined: Sun Mar 22, 2015 7:36 am

Re: lirc has to be manually retarted after boot

Sun Mar 22, 2015 7:53 am

I found this post while trying to solve this issue on my Pi2. Wasn't much help but noticed someone had resurrected it and was having the same issue with rc.local not launching lirc either.

I have made this somewhat dirty solution.

From terminal/CLI launch crontab for the PI user.

Code: Select all

crontab -e
Scroll to the bottom and enter this code:

Code: Select all

@reboot  (/bin/sleep 30; sudo su root /etc/init.d/lirc start) > /home/pi/pi.txt 2>&1
What this does:
Installs a crontab job that runs each boot, reboot etc;
Sleeps for 30 seconds to ensure Kodi is up;
Runs the /etc/init.d/lirc start command as PI user with root privileges (for some reason, in my build, the root crontab was not capable of launching this - I am yet to investigate why);
Pipes out the crontab job result to a text file at /home/pi/pi.txt (the Pi home directory - good for error checking if it stops working).

It's not pretty but mine wasn't working on the latest (and final) RaspBMC build. This solved it. Hope it works for others too.

P.S. Sorry to add to an other wise dead thread - just figured the last poster may still be looking for a solution.

Return to “Automation, sensing and robotics”