Comment 6 for bug 1490991

@Ken

So although we have a pending fix that's been merged in our ofono trunk, I still would like to better understand what caused the crash during autopilot testing.

The fix removes an assert in the ril device plugin when the radio state becomes UNAVAILABLE and the plugin's online flag is TRUE. Essentially this assert is saying, if the radio ever goes OFF/UNAVAILABLE by itself without instruction from ofono, this is something that can't be handled... so assert, upstart restarts ofono, and in theory the system recovers.

That said, we never really thought thru what happens during system shutdown. As ofono is never told the system is shutting down, then whenever the container shuts down rild, it triggers the radio unavailable scenario and the assert happens, which could potentially lead to more than one crash/restart.

NOTE - with the proposed fix, UNAVAILABLE state transitions are *ignored*, however if OFF occurs instead, the same assert will still fire.

Can you or someone from your team isolate the AP test case that causes the failure? FlightMode shouldn't trigger this error as urfkill tells ofono to go offline, which triggers a RADIO POWER OFF message to rild. This sequence results in the plugin's online flag being set to FALSE *before* the radio power message is sent, so in theory, the assert should never happen.

If we have other non-shutdown scenarios that trigger the radio UNAVAILABLE state, ignoring the state may not be the wisest course of action.

Perhaps it's worth changing the assert to a graceful exit, returing a non-success error code, which would still allow upstart to restart ofono, but would no longer leave .crash files laying around.

Finally, we might also want to consider whether additional shutdown logic for ofono, urfkill, and other components in the networking/telephony stack is required. Note, there may be hooks and/or logic for shutdown in some of these components, however the timing might not be properly synced with the container shutdown.