Use of supervisord inflates the microvm size by 110MiB, which is… a lot

[nagisa]

Recently virtiofsd has been moved to run within microvm and furthermore this is now managed by supervisord, which requires python3.

This increases the size of the VM closure by a very significant amount for a µVM:

python3: ∅ → 3.12.7, +110778.7 KiB
python3.12-setuptools: ∅ → 75.1.1, +13312.8 KiB
python3.12-supervisor: ∅ → 4.2.5, +5527.2 KiB

(Yes, I'm surprised python3 is this large!)

Could there be other options for this task that aren't as size-intensive?

[astro]

Cc: @SuperSandro2000

[SuperSandro2000]

We could replace python with python3Minimal which is not really supported in nixpkgs because it is for bootstrapping and it will cause a cache bust for most of python packages. This will probably trigger more rebuilds than just supervisor because test dependencies need to be build, too and we really want to run tests that nothing is missing.

I don't know any other program to manage services that is not literal a pile of shellscripts and could be used here.

[nagisa]

I took a very brief look at the PR which introduced supervisord (#257?) and wasn't able to understand the "why" of it being introduced (nor why the disown was necessary in the preceding code.) Without that it is really difficult to tell what the introduction addresses and what other tools would serve the need.

In particular in my mind systemd is a service manager that already exists in every VM and it can be run in a --user mode if a separately controllable instance is needed. At the same time I don't know what we're using supervisord for exactly, so it might very well be that systemd is not an appropriate replacement.

[nagisa]

That said, it probably isn't the use of supervisord itself that's a particularly painful problem. The host will almost inevitably have python3 anyway. But the recent move of the service into the VM in #291 has made it something much more apparent.

[SuperSandro2000]

Normally we need to run at least 3 processes in one templating unit. To properly start and stop virtiofsd, we need to properly forward signals. Using bash job control and putting processes on the background does not work for that. This is not inside the VM but on the host and having to deploy the host for every change in any mount is also not convenient.

Having it inside the microvm derivation that is run on the host makes it easier to template and avoids some templating problems.

For us the change in python3 didn't really make any difference and it was already there in most VMs anyway.

[Sohalt]

What about using https://github.com/F1bonacc1/process-compose instead of supervisord?
That's a go binary, which is only 14M.

[SuperSandro2000]

I couldn't find anything in the readme or doc what happens when a signal is send to process-manager.

Also this is a really desperate move to save yourself 86MB but in other deployments like most of ours this will be a net +14MB addition.

Also with rewrite of the activation script on Python the gain will be nullified in the next release or the one after that.