#9 Irexec process dies on suspend/hibernate [duplicate of #22]

1.0
closed
nobody
irexec (4)
2014-09-09
2014-07-16
Deve
No

Hi,

I'm not sure if you have already any solution for this, but AFAIK you need run irexec as separated process/daemon to execute commands.

When you restart lirc daemon you need also restart irexec. If remote controller is disconnedted for a while then once again - you need to restart irexec. It would be much easier when irexec would be integrated with lircd.

This is actually few lines of code. Detect if signal should be sent to irexec and in this case don't send it. Simply execute this command. Or use different name in lircrc, for example "prog = execute" or "execute = true".

Discussion

  • Alec Leamas
    Alec Leamas
    2014-08-14

    Hm... I actually don't think this is a good idea (?) The main problem is that in a common scenario of today lircd runs as root whereas irexec runs as a regular user within a session.

    It could be possible if we were able to run lircd as a regular user. But even so, the normal setup would be that lircd runs as some daemon user, but irexec as part of the desktop session.

    I myself solve this this with a launcher script which restarts irexec if/when it dies. Once systemd finishes their job with session management, there will be really good options for this. But that is not now, unfortunately.

    leaving open for now.

     
  • I tend to agree with the suggestion. Having a deamon just listening to a socket and execute commands is generally a source of problems, and is not an elegant solution.

    Traditional Unix programs like sendmail and at work like that: if they find a script/program that belongs to a certain user (e.g. in his home directory) they fork and change their user id to that of the owner of the file, before doing things on behalf of that user. This of course assumes running as root.

    Finally, this would be an additional possibility, not enabled by default. It would not break the present solution.

     
  • Alec Leamas
    Alec Leamas
    2014-08-17

    There actually seem to be a lot of things lurking around here. For now, some more thoughts:

    • lirc is actually built around the idea of multiple client connecting to the lircd socket to get their input. This is what's supported by major linux htpc applications like vlc, XBMC and mythtv. If we cannot build a simple client like irexec which works reliably, how can we then convince others support lirc in their applications?

    • The user switch needed between the daemon user (root or not) and the typical, regular desktop user is a strong incentive to run irexec in it's¸own process.

    • We should not build new functionality requiring root privileges.

    • irexec can die for a number of reasons, including non-forked shell code and the lircd socket being teared down. It might make sense to add options to
      irexec to handle this by restarting a new daemon if the original dies (care taken to not spawn excessive).

    • lircd is certainly not designed for the modern kernel hot-plugging of devices, notably usb hardware. Perhaps there should be way for the driver to
      inform lirc that the device is no longer present?

    • Question remains open why lircd needs top be restarted. In the typical HTPC scenarios i have seen such restarts are not required. So: why/when are these lircd restarts done?

     
  • Deve
    Deve
    2014-08-18

    In reply to your last question: restart lircd is rather not needed. Maybe only if you change something in configuration. But irexec is closing also in other cases - for example when you suspend/hibernate your OS. You need to restore it manually or from pm-utils script (which is executed as root, so you must do something like "su user -c irexec"). Irexec probably also will close when you disconnect the device.

    XBMC and irexec are two different things. The second one runs everytime as daemon in background.

    Use another script which checks if irexec daemon dies is rather not elegant solution. You add another daemon to your system which runs in background. And everyone must write it manually, using bash script or cron.

    There could be options in config file: run_irexec, run_irxevent, irexec_process_owner, etc. Lircd could run irexec at startup and check if irexec dies.

    Or maybe just workaround it in irexec and keep it always alive? Do self-restart if it's needed?

     
  • Alec Leamas
    Alec Leamas
    2014-08-18

    So:

    restart lircd is rather not needed

    Which means that we can leave this aspect.

    But irexec is closing also in other cases - for example when you
    suspend/hibernate your OS. You need to restore it manually or from
    pm-utils script (which is executed as root, so you must do something
    like "su user -c irexec").

    So, here we basically have a bug (RFE?) for irexec that it does not handle suspend/hibernate.

    Irexec probably also will close when you disconnect the device

    Could you please check up this and give a more precise description?

    Use another script which checks if irexec daemon dies is rather not
    elegant solution. You add another daemon to your system which runs
    in background. And everyone must write it manually, using bash
    script or cron.

    Agreed.

    There could be options in config file: run_irexec, run_irxevent, irexec_process_owner, etc.

    Agreed. Any new command line option should be reflected in lircd_options.conf

    Lircd could run irexec at startup and check if irexec dies.

    No (see user switch discussion above). But irexec could spawn two processes, and let the parent handle if/when the child dies. Or something else, but it should survive suspend/hibernate and hardware devices being unplugged.

    EDIT:

    Or maybe just workaround it in irexec and keep it
    always alive? Do self-restart if it's needed?

    Yes, but we should not change the current default behaviour i. e., if possible not break current installations It should be governed by one ore more new command line options

     
    Last edit: Alec Leamas 2014-08-18
  • I strongly discourage to put any user level configuration into lircd. lircd already has some limited hot-plugging support, so it won't disconnect clients if you remove your USB receiver. If lircd dies in any other situation than manual restart, this should be fixed instead of trying to fix symptoms.

     
  • Alec Leamas
    Alec Leamas
    2014-08-18

    I agree with Christoph. Re-phrasing subject line, focusing this bug on the suspend/hibernate issue.

    Dave: If you indeed have a problem with irexec dying when you "disconnect the device", please file a separate bug.

     
  • Alec Leamas
    Alec Leamas
    2014-08-18

    • summary: Irexec support embedded in lirc daemon --> Irexec process dies on suspend/hibernate.
    • status: open --> accepted
     
  • Alec Leamas
    Alec Leamas
    2014-08-19

    • labels: --> irexec
     
  • Alec Leamas
    Alec Leamas
    2014-08-27

    • status: accepted --> need-info
     
  • Alec Leamas
    Alec Leamas
    2014-08-27

    Dave: After this experience in [tickets:#22]: is this also related to the udev rules? Do you still have this problem if you remove them?

     

    Related

    Tickets: #22

  • Alec Leamas
    Alec Leamas
    2014-09-02

    Without any more input I'll eventually close this bug, assuming that it is a duplicate of [tickets:#22].

     

    Related

    Tickets: #22

  • Deve
    Deve
    2014-09-09

    I didn't even check it yet... But it was very similar to #22 and it should work after removing udev rules.

     
  • Alec Leamas
    Alec Leamas
    2014-09-09

    OK. we close this one. Thanks for reporting (and forgive me I misspelled your name)

     
  • Alec Leamas
    Alec Leamas
    2014-09-09

    • summary: Irexec process dies on suspend/hibernate. --> Irexec process dies on suspend/hibernate [duplicate of #22]
    • status: need-info --> closed