Python libmm problems
Colin Helliwell
colin.helliwell at ln-systems.com
Fri Sep 15 15:34:04 UTC 2017
> On 14 September 2017 at 17:11 Dan Williams <dcbw at redhat.com> wrote:
>
> On Thu, 2017-09-14 at 15:35 +0100, Colin Helliwell wrote:
>
..
> > Thanks Dan. I've persevered with GLib, and made a bit of progress.
> > On top of your suggestion - instead of the start-up "modems =
> > manager.get_objects()" etc, I've hooked in [a derivation of] the
> > ModemWatcher example, and pass an instance in the
> > timeout_add_seconds() instead of 'modems[0]'.
> > Getting somewhere under normal circumstances, but I've found that if
> > MM is restarted whilst the script is running, then get_modem_state()
> > no longer gets called at all. The ModemWatcher instance *is* still
> > spotting the presence of the modem, even if I unload its driver after
> > stopping MM and reload it after MM is restarted.
> > Something, I guess, has got unhooked in the event driving...?
>
> When MM gets restarted, that object is no longer valid because it went
> away when MM quit. So you need to find the new modem. Also, if you're
> using modem paths, you cannot be sure that the modem path from before
> MM restart will be the same modem after MM restart.
>
> In any case, one thing you could do is to pass the modem reference to
> the timeout function rather than an actual modem object, and re-look-up
> the modem using that reference every time. A bit inefficient, but if
> you don't want to use signals to listen for MM restarts, that's one
> simple option.
>
> Dan
It does *seem* that the items I'm using are remaining valid across an MM restart.
The main problem in what I had was that the handler had an 'else' clause which was resulting in the handler returning False and hence not being re-run.
Though this is coming together nicely now, I don't need the script to run forever once it's done its stuff. Is there a way send a HUP/TERM to itself?
More information about the ModemManager-devel
mailing list