Weird snap automount.

Murphy · 18 Sep 2023 at 11:42

On my learning Linux adventure I've come across a why is it doing that situation, i always think it's a good idea to familiarise yourself with an OS so you know what's normal and what's not, going through various logs and tweaking/playing around with things I've learnt a lot.

However snap being snap this one has left me at a dead-end, my Google-fu must be letting me down so I'm hoping someone maybe able to point me in the right direction, I'm not necessarily wanting to know how to fix this as it's not causing any issues but it would be nice to know why or how it's happening. Essentially journald is being spammed with the following...

Code:

systemd    proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 508 (snap)
systemd    proc-sys-fs-binfmt_misc.automount: Automount point already active?

The triggered by number will change after 20-30 entries but essentially journald gets spammed with 100 odd such entries, i know snap automounts snap images but AFAIK it shouldn't be trying to automount things 100 odd times.

So anyone got any idea why it's making so many request to binfmt_misc?

dreamcat4 · 18 Sep 2023 at 12:38

hmm idk. but here is a basic line of questioning:

* what snaps do you have installed and/or running that uses non-elf binaries in them? ---> because this should be for the reason.

but the main question is around:

rationale / reasoning as to why you think this it is considered weird --> its not due to your own lack of familiarity here. its because snapd and snaps themselves are weird.

and if you believe this to be a good quality software... well it then goes away (such argument), to install some snaps and measure real terms application startup performance versus it's leading competitor (which is flatpaks). to then see how harmless 'its weird' actually is these days. whether that aspect is actually tolerable in recent release or not:

i have no idea myself. because after discovering this very poor and intolerable performance issue they have then been disabled permanmently onto my system and for many months now. (and still not seeing any new or solid reasons / benefits here to re-enable the snapd service for myself since that time).

the bottom line is: that if you dont like the spam, then disable snapd and dont use snaps... and it will get rid of such spam.

because ubuntu itself actually does not yet require very much snaps, at least not until several releases, to then be required for manadory and essential system components.

Reddit - Dive into anything

www.reddit.com

Murphy · 18 Sep 2023 at 15:27

Other than the basic snaps that came with Kubuntu none, i replaced the Firefox Snap for the deb version because like a lot of people i don't like snaps. I'm not much for containerised packages at all if I'm honest, however I've kept the basic Snap infrastructure in place because i want to avoid any potential problems down the road when it comes to upgrading to the next LTS.

The bottom line is I've masked the proc-sys-fs-binfmt_misc.automount service so it's not spamming the logs any more but I'd still like to try understanding a little more about why or what's causing snap to attempt so many mounts. I had already read that Reddit post and it helped to understand a bit more but i still don't really understand why snap would be doing that or even why you'd mount something simply to recognise a different binary format on the CLI.

dreamcat4 · 18 Sep 2023 at 16:06

Hmm...

binfmt_misc - Wikipedia

en.wikipedia.org

Well if i understand correctly, (which maybe I am not totally 100% on)... but it's sysdemd lazy-loading capabilities is why the automount service exists. Rather than being purely only a regular mandatory startup service.

For example:

Lets say your system boot sequence always loads this up certain well knowns formats (such as .exe for wine). And those are not affected...

However then 1 day you decide to install libretro / MAME emulator. And wants to start using it without a full system reboot. Then a post install hook on the .deb pkg setup set (at the end). Would then trigger a new automount service to load up something that was just optionally installed by the MAME emulator.

And then if you were to either remove all of MAME, or just some specific sub-packages for the supporting libretro libraries (for example some specific individual emulators)... then it can remove.

Or same situation if you maybe installed some Virtual Machines based emulators things. Like QEMU packages that then emulates ARM cpus... things like this.

In short, it would be a bad idea to mess about deactivating this service now. Since when it actually breaks will be at some other completely random time. And you would have long forgotten what you had done here. Thinking it was harmless actions. Then be scratching your head as to why QEMU or MAME is (later on) randomly gotten broken on your system. Despite dutifully following to the letter all of it's so-called "guaranteed to works" install steps.

This i feel was a more risky thing to do than disable snapd service. Which still currently has "no known" reson to require it for even the next LTS.. for which that particular decision has already been set, and if ubuntu does end up requiring snaps AFTER that next LTS release, then you are sure to hear alls about it! (because there will be many prominent news stories / articles complaining).

Murphy · 18 Sep 2023 at 16:57

From my understanding and going on the kernel documents, like you I'm not 100%, it's used for a proc mount.

Kernel Support for miscellaneous Binary Formats (binfmt_misc) — The Linux Kernel documentation

It seems to be used for interpreting unknown binary formats into something Linux knows what to do with, so if you had something like a .com or .exe it would know to open those in Wine or whatever.

The Arch wiki shows how it works with Java but the principal is the same for other file types...

Binfmt misc for Java - ArchWiki

wiki.archlinux.org

I have my suspicion that snap is remounting the root FS read only, as it does to containerise snaps, but for some reason when it does that it's trying to either remount the original /proc/sys/fs/binfmt_misc or trying to mount the /proc/sys/fs/binfmt_misc in the read only version of what it mounted.

Either way the only thing binfmt-misc is doing is setting up interpretation for Python so i guess I'll see how it goes.