Symptom: When disconnecting an irtoy usb transceiver at runtime i end up with lircd running at 100% in an endless loop.
See comments in attached example patch for details. A root cause might be my setup (embedded/buildroot), but maybe it happens in other setups as well..
First, lircd does not, nether offically or in practice, support dynamically changing hardware, so what you describe in the title is not a bug in the strict sense, and does not "need" fixing.
Having said that, detecting that a loop is actually going nowhere is of course a good thing. But calling exit is not allowed in a plugin -- the argument should be known.
Agree on both. The patch is actually what i do in my setup (where the irtoy disconnects itself rarely for whatever reason), and the exit causes everything to restart properly via the init system (is there a better way to do a graceful recovery?).
I have patched it this way and thought it might be worth reporting.
What i actually did not understand in the code why it accepts a read() return code of 0 (rc >= 0 statement in loop condition). If poll returns OK i would expect that read returns data.
I shouldn't call it "gracefully" but there is indeed an official way: sending a USR1 signal to the process, which causes lircd to make a clean exit. This is actually documented in the lircd manpage, and used by the file driver to terminate the lircd process on input file EOF. S
lirc assumes that the hardware is there and does not disappear. I don't think doing an exit in drivrer code is correct. The main event poll loop should realise there is nothing it is waiting for and simply exit the loop.
Fixing this correctly requires re-writing a lot of code. Patches are welcome but as lirc is really in bug-fix only mode this is more than we are willing to do.