Hi,
we’re running our custom wifi configuration utility, which behaves more or less in a similar manner to resin-wifi-connect. However, once we have stopped NetworkManager via DBUS, after a while NetworkManager is restarted (most likely) by the resinOS. We are not re-starting the NetworkManager in our app at all.
Is there any service, other than NetworkManager it self, that would depend on NetworkManager and thus restart it?
//Edit: Running Resin OS 2.0.8+rev1 (prod) with supervisor 5.1.0.
Hey @kipe .
I just ran a test on my resinOS v2.2.0 .dev, I setup a console into the device and stopped networkManager with systemctl stop NetworkManager and then have just been pinging from the host for the last hour and the network is still down. How long does it usually take to automatically reconnect?
Still got this test running and NM hasn’t come back up. @kipe are you running systemd (INITSYSTEM=on) in the container, or something like that?
We’re running with INITSYSTEM=on, but it does seem like the issue lies somewhere in our own codebase after all… Once we figure it out, I’ll post the reason here, just in case someone else runs into similar issues.
Hey, just a brief update, will confirm this tomorrow, once we’re back at the office and can start looking into this a bit more (currently all test devices offline because of searching of the bug 
)
Seems like the issue lies in how we handle messages coming from NetworkManager (we listen to the messages coming through dbus). It seems like we’re still receiving messages after we’ve stopped NetworkManager, which of course causes issues in our state handling. So, it’s just a matter of improving the state handler so that we’re not altering the state, once we have decided to start the AP for configuring the wifi.