Avoid Using Snaps on Small VMs

If you're using light instances on cloud infrastructure, one thing you should avoid doing is using snaps as part of your machine setup. While using snaps is supposed to make software packaging and deployment easier, I've managed to run into a restart cycle with the snapd service where the launching of a snap takes too long and and systemd comes around to kill the offending process to have it start again.

You'll find something like the below in your logs in /var/log/syslog

Dec  6 02:08:51 host snapd[140981]: AppArmor status: apparmor is enabled and all features are available
Dec  6 02:10:15 host snapd[140981]: AppArmor status: apparmor is enabled and all features are available
Dec  6 02:10:18 host systemd[1]: snapd.service: start operation timed out. Terminating.
Dec  6 02:10:18 host systemd[1]: snapd.service: Failed with result 'timeout'.
Dec  6 02:10:18 host systemd[1]: snapd.service: Scheduled restart job, restart counter is at 98.

And you'll see that your CPU cycles are just getting eaten up by the spinning service:

A problem like this is not ideal and sadly it will make your virtual machines unresponsive (I had problems with ssh, database access and more). The best thing to do for machines that don't have a lot of cpu power is to avoid snaps and that will avoid grief when it comes to finding your servers intermittently not working.

I used snaps in this case to run a containerized version of certbot, which helps manages the certificates for this site and once killing the process goes back to normal.