/usr/lib/snapd/snapd:11:runtime:runtime:runtime:runtime:runtime

[errors.ubuntu.com bug bridge]

The Ubuntu Error Tracker has been receiving reports about a problem regarding snapd. This problem was most recently seen with package version 2.38+18.10, the problem page at https://errors.ubuntu.com/problem/5e58e04cdc647a1fd50f71f02724dd0b5b8c1f4b contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports.
If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/.

[Zygmunt Krynicki (zyga)]

It looks like an udev/netlink related panic in snapd

[Paweł Stołowski (stolowski)]

I think the bug is in the go-udev package (upstream). The Monitor() function returns a 'quit' channel that the caller uses to stop processing. Monitor() runs a backgroud goroutine that monitors/reads from netlink socket and stops if quit channel is written to. I think the problem is that the quit channel is a buffered/non-blocking channel - writing to it and calling Close() on the netlink object right afterwards (which we do when stopping snapd) means we might be closing the socket and disposing the object when the background routine is reading netlink events.

The fix should be simple, I'll look at fixing it in our source tree (conviniently this dependency is forked under our project) and will carry the fix upstream.

[Paweł Stołowski (stolowski)]

The bug may occur regardless of experimental hotplug flag, and may prevent clean shutdown of snapd - of course only if there is udev netlink activity, therefore setting to critical.

[Paweł Stołowski (stolowski)]

My initial conclusion about go-udev being the culprit was premature, the socket closing & quit channel code looks fine after all, the problem lies somewhere else and may be something in the go runtime stack and it's very unclear for the time being.