Comment 2 for bug 1657104

I ran into this in recover mode in uc20 with a small tmpfs mounted for ubuntu-data and got the following snapd log/panic https://pastebin.ubuntu.com/p/6BkjjssQpt/

I think that at a minimum, before the full fix of having snapd estimate how much disk space is required for an operation and cancel before filling up the disk, we should figure out how to at least make snapd service failover eventually fail such that snap-failure gets started up because as it is, snapd takes so long to start up (and thus times out) that we don't hit the StartLimitBurst and StartLimitIntervalUsec default settings (and snapd.service doesn't configure these for itself) and thus snap-failure never gets started.

If we at least hit the restart limit, then that would give snap-failure an opportunity to cleanup partial downloads so that snapd could start itself back up. But note that snap-failure currently would just revert snapd which may or may not be sufficient to unbreak snapd here. Ideally also snap-failure would detect that the disk is full and instead of reverting snapd revision it would just clean up the disk for snapd and leave some kind of flag for snapd to know that it should give up on it's current set of changes/tasks in flight due to disk space issues.