[Intrepid AMD64] lirc daemon fails to load at startup

[Jean-Paul]

Binary package hint: lirc

I use Intrepid AMD64, and it so happens that lirc always fails to load when the system boots.
The weird thing is, that when I use the "sudo /etc/init.d/lirc restart" command afterwards, lirc loads properly.

The nasty side effect is that I always have to reload lirc by hand before I can use my media center remote.

[Nick Fox (nickj-fox)]

Is Lirc failing to load, or is it loading after X starts? Please confirm.

-Nick

On Tue, Feb 24, 2009 at 8:29 PM, Jean-Paul <email address hidden> wrote:

> Public bug reported:
>
> Binary package hint: lirc
>
> I use Intrepid AMD64, and it so happens that lirc always fails to load when
> the system boots.
> The weird thing is, that when I use the "sudo /etc/init.d/lirc restart"
> command afterwards, lirc loads properly.
>
> The nasty side effect is that I always have to reload lirc by hand
> before I can use my media center remote.
>
> ** Affects: lirc (Ubuntu)
> Importance: Undecided
> Status: New
>
> --
> [Intrepid AMD64] lirc daemon fails to load at startup
> https://bugs.launchpad.net/bugs/334144
> You received this bug notification because you are a member of Mythbuntu
> Developers, which is subscribed to lirc in ubuntu.
>

[Jean-Paul (jeanpaul145)]

The kernel module loads fine, from what I can see:
When I "sudo /etc/init.d/lirc restart", it starts working without having to load the kernel module again (in my case lirc_mceusb2).

The daemon tries to load when the boot progress bar is showing (alt+ctrl_F2 giving me a view of what happens), _before_ I get a gdm login screen, so I'm assuming that it is also before X loads.

[Nick Fox (nickj-fox)]

Please post a link to your logs from Mythbuntu Log Grabber. This will help
further the diagnostics.

-Nick

On Wed, Feb 25, 2009 at 6:11 AM, Jean-Paul <email address hidden> wrote:

> The kernel module loads fine, from what I can see:
> When I "sudo /etc/init.d/lirc restart", it starts working without having to
> load the kernel module again (in my case lirc_mceusb2).
>
> The daemon tries to load when the boot progress bar is showing
> (alt+ctrl_F2 giving me a view of what happens), _before_ I get a gdm
> login screen, so I'm assuming that it is also before X loads.
>
> --
> [Intrepid AMD64] lirc daemon fails to load at startup
> https://bugs.launchpad.net/bugs/334144
> You received this bug notification because you are a member of Mythbuntu
> Developers, which is subscribed to lirc in ubuntu.
>

[Jean-Paul (jeanpaul145)]

You can find the logs on http://mythbuntu.pastebin.com/f43e5a00f

[Mario Limonciello (superm1)]

Hi Jean: can you try to remove the -k in the init script? If that fixes it, this is a duplicate of bug 344781

[Jean-Paul (jeanpaul145)]

Where, do you mean the -k argument to the modprobe command in the "load_modules ()" function in /etc/init.d/lirc ?

Also, this is an interesting bit: While, at the moment, I still get a FAIL from lirc at boottime, once I've logged in to a Gnome session, I can now use my remote without restarting the lirc daemon (as opposed to the situation I got at boottime).

[Jean-Paul (jeanpaul145)]

If that IS what you meant: it didn't fix it.

As I stated in my previous post, the remote works now without me having to manually restart the lirc daemon, but the FAIL still appears at boottime.

I also tried something else: after my desktop was booted (and tried out the remote), I tried to do "/etc/init.d/lirc start" instead of restart. Got me a solid

"
 * Loading LIRC modules [ OK ]
 * Starting remote control daemon(s) : LIRC [ fail ]
"

So I was thinking: perhaps there is something else starting the lirc daemon earlier in the boottime, causing the "FAIL" to appear at boottime because the daemon is already started. The $64k question is then: what can do that?

[Mario Limonciello (superm1)]

Yes this is possible. Do this then:

ps aux | grep lircd

That will show if it's running. If it is, it can get started via udev earlier.

What you can do is add a "set -x" to the top of /etc/init.d/lirc for debugging too.

[Jean-Paul (jeanpaul145)]

I think that udev is indeed starting the lirc daemon (and loading the lirc kernel module). Attached to this post is my udev logfile (I assume it's from the last time I booted my machine). If you search for lirc you'll get a few hits, including for lirc, lirc_dev and lirc_mceusb2.

Question is: is this (lirc started by udev) functionality that is useful to keep?
And if so, what can be done to make it play nicely with the script in /etc/init.d/?

[Mario Limonciello (superm1)]

I personally think it's useful because it will start and stop the daemon if
you hotplug the device. I've actually used such functionality previously
successfully myself. I'm not sure what about it is breaking your
configuration however..

[Jean-Paul (jeanpaul145)]

I don't exactly know either. I mean, I did manually set up some mappings for my remote for rhythmbox (just to get basic functionality - start, stop, next, previous, and volume +/-), but I can't imagine that something so far up the software stack can interfere with something like loading the daemon and the kernel modules.

[Christoph Langner (chrissss)]

I can confirm this issue. I have to restart lirc to make it work too... I own some kind of those chinese "x10 remotes" which i rund with lirc and --driver=atilibusb. When i boot my computer lircd is running

$ ps aux | grep lircd
root 2881 0.0 0.0 18032 576 ? Ss 05:58 0:00 /usr/sbin/lircd --driver=atilibusb
nobody 3164 0.0 0.0 12360 508 ? Ss 05:58 0:00 /usr/sbin/inputlircd /dev/input/event0 /dev/input/event1 /dev/input/event2 /dev/input/event3 /dev/input/event4 /dev/input/event5 /dev/input/event6 /dev/input/event7
toff 14079 0.0 0.0 7532 904 pts/0 R+ 08:32 0:00 grep lircd

But when i try to get signals via

$ irw

nothing happens. irw doesn't give a single line of output. When i restart lirc with

$ sudo /etc/init.d/lirc restart

and repeat

$ irw
00000014e00b0000 00 program+ x10
00000014e00b0000 01 program+ x10
00000014e00b0000 02 program+ x10
00000014e00b0000 03 program+ x10
00000014e00b0000 04 program+ x10
...

irw reacts on key press. In other words, after a reboot i have to restart lirc to make it work. I'm using here Ubuntu Jaunty 64-bit with all the latest updates installed.

$ dpkg -l lirc* | grep ii
ii lirc 0.8.4a-0ubuntu4 infra-red remote control support
ii lirc-x 0.8.4a-0ubuntu4 infra-red remote control support - X utiliti
$ uname -ar
Linux isleofskye 2.6.28-11-generic #40-Ubuntu SMP Fri Apr 3 17:39:41 UTC 2009 x86_64 GNU/Linux

[Wilbert Volkers (wilbertvolkers)]

It seems to work fine after i added the line "sleep 1" directly after "modprobe" in "/etc/init.d/lirc".
In my case sometimes it would start-up so i reasoned that maybe it needs a bit more time. Let me know if this really is a bad idea.

[Mario Limonciello (superm1)]

Well if that solution works, it sounds like this is definitely a race
condition bug, but that sleep is masking the race.

On Mon, Apr 13, 2009 at 08:26, Wilbert Volkers
<email address hidden>wrote:

> It seems to work fine after i added the line "sleep 1" directly after
> "modprobe" in "/etc/init.d/lirc".
> In my case sometimes it would start-up so i reasoned that maybe it needs a
> bit more time. Let me know if this really is a bad idea.
>
> --
> [Intrepid AMD64] lirc daemon fails to load at startup
> https://bugs.launchpad.net/bugs/334144
> You received this bug notification because you are a member of Mythbuntu
> Developers, which is subscribed to lirc in ubuntu.
>

[Jean-Paul (jeanpaul145)]

Bug appears to still be present in Ubuntu Jaunty. During boot I still see the FAILED message for the loading of the lirc daemon.
However, at least in KDE 4.3's lirc modules (I have KDE4.3b2 installed right now), it works fine (after configuration of the KDE module, of course).

[Nathan Miller (nate-natemiller)]

I am seeing the same bug in Ubuntu Jaunty. It does appear as though it is attempting to load twice. I'm not using KDE as I'm just running a minimal install with XBMC. My remote is working yet it shows a fail message at every reboot.

[Ghost Rider (jakob-lichterfeld)]

I had the same problem in Jaunty, but i solved it.
I think that it isn`t a bug. It is caused by a wrong installation.

If you edit the hardware.conf and the lircd.conf manually you have to uninstall the inputlirc package. If you have installed this packed, the lirc-daemon is loaded twice at startup and you have to restart it before it works.

Hope this helps.

[Jean-Paul (jeanpaul145)]

I've edited neither /etc/lirc/hardware.conf nor /etc/lirc/lircd.conf manually.

[electoys (electoys)]

I'm having this problem on Mythbuntu Karmic. I've troubleshooted it to a race condition. While /etc/init.d/lirc is starting the daemon, another process restarts (stops and starts) it. Sometimes it overlaps to cause a failure and sometimes it still works.

Why is the bug still "unassigned"?

[Pete (pjderooy)]

Ghost Riders suggestion worked for me.
Symptoms were that lircd was loading correctly, irw worked correctly, but the remote (MCE USB) would not work in MythTV.
Exiting MythTV frontend, restarting lirc, and restarting Myth would get the remote working. Completely removing inputlirc fixed the issue.

[Christoph Langner (chrissss)]

Can someone delete the spam above?

[Alec Leamas (leamas-alec)]

Anyway, we believe this is fixed in last update lirc-0.9.4c:
  - The udev rule restarting lircd when /dev/lirc0 is created is removed.
  - 0.9.4 sports a much simpler systemd setup, which certainly can have problems but not this.

Closing

lirc (0.9.4b-0.1) experimental; urgency=medium

  * Non-maintainer upload.
  * First shot on major upstream updates.
    - Re-packaged from scratch based on new dh primitives.
    - Thanks for help on debian-mentors!
  * New upstream release 0.9.4
    - Release 0.9.1 .. 0.9.3 was never packaged.
    - Old 'lirc' service split into separate systemd services:
      lircd.service, lircmd.service and irexec.service.
    - Remote definitions moved out of lirc to new project
      lirc-remotes; affects large number of LP issues.
    - Builds also on FreeBSD 10.3.
    - Fixes "Not updated to last version" (Closes: #777199),
      LP: #1443590.
    - Fixes "Default device for mode2 is /dev/lirc" (Closes: #702140).
    - Fixes "/var/run/lirc contents disappear..." (Closes: #676343).
    - Fixes "lircrcd segfaults" (Closes: #780062).
    - Fixes "'/etc/init.d/lirc restart' is broken" (Closes: #782091).
    - Fixes "Prompting due to modified conffiles..." (Closes: #655969).
    - Fixes "LIRC installs bad udev rule" (Closes: #804397),
      users depending on this rule will need to explicitly start lircd.
    - Fixes "lirc init script can create circular symlinks", LP: #698007.
    - Fixes "Update Uploaders List (Closes: #762554).
    - Fixes "Please switch to libftdi1" (Closes: #810370).
    - Fixes LP: #153457 "iguanaIR support not functional".
    - Fixes LP: #460027 "using lirc init script restart function fails
      sometimes".
    - Fixes LP: #499588 "lirc udev rule causes unreliable startup".
    - Fixes LP: #567519 "lircd(8) mentions non-existent
      /dev/input/uinput".
    - Fixes LP: #1029604 "mce remote doesn't work due to out of date
      lircd.conf.devinput".
    - Fixes LP: #1312287 "lircd start problem".
  * The built-in irman support is moved to the lirc-drv-irman package.
  * Revised package structure: keep old liblircclient0 (renamed to
    liblirc-client0). Adding new packages liblirc0, liblirc-dev and
    lirc-doc. Former liblircclient-dev merged into new liblirc-dev.
  * Don't overwrite existing lircd.conf file.
  * Ship sysV scripts from the svn tree [Stefan Lippers-Hollmann]
  * Add handling of obsolete 0.9.0 udev rule restarting lircd
  * Old lircd output socket link /dev/lirc dropped. Use
    /var/run/lirc/lircd.
  * Updated copyright
  * Update compiler flags: -Wl,as-needed + hardening
    [Stefan Lippers-Hollmann]
  * Avoid negative architecture deps like [!hurd] (Closes: #634807)
    [Stefan Lippers-Hollmann]
  * Add patch 0007-tools-remove-configs-symlink.patch + explicit link
    to walk around #801719 (dh_python3 shortcomings).
  * Last parts of libirman dependencies removed.
  * Changing Vcs-* headers to point to upstream packaging branch.
  * Fixes existing large number of upgrade bugs.
  * Enhance hardening flags.
  * Add a lintian pbuilder test, this requires --hookdir and B92-test-pkg
    therein.
  * Tested (build-wise) on stretch and sid.

 -- Alec Leamas <leamas.alec@gmai...