these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
We were setting the systemd pre-start script through the
systemd.services.<name>.preStart NixOS option. This option uses a
string containing the pre-start script as input.
In some scenarios, you want to extend this script to perform some
additional actions before launching a container.
At the moment, your only option is to mkForce the pre-start string and
rewrite a preStart script from scratch. Potentially vendoring the
Nixpkgs pre-start script in your custom pre-start script. (you can
also create a new service unit in charge of running the custom
pre-start and create a dependency link between the units, but that's
also sub-optimal).
The systemd.services.<name>.serviceConfig.ExecStartPre NixOS option
gives us a better way to extend a pre-start script. Instead of being a
simple script, this option can be a list of scripts. The NixOS module
system then merges the multiple list declarations instead of
overriding them. Meaning that if we use this ExecStartPre option, we
can trivially extend the exec-start script: just add the custom script
in the systemd service override and you're done.
ExecStartPre behaves a tiny bit differently from preStart. Instead of
expecting a string containing a script, it expects a path pointing to
a script. We take advantage of this API change to check the pre-start
script with shellCheck via the pkgs.writeShellApplication function.
Without `ìmageFile` set, the service needs to download the image from
the registry. If the network is not up in time, the service tries to
restart rapidly until it fails.
This has a number of benefits such as that applying service limits will
actually work since there isn't a layer of indirection (the Docker daemon)
between the systemd service and the container runtime.
As a novice to using this module, I found the existing description to be
quite misleading. It does not at all disable pulling from the registry,
it just loads some image archive that may or may not be related to the
container you're specifying. I had thought there was extra magic behind
this option, but it's just a `docker load`. You need foreknowledge of
the contents of the archive so that whatever it contained is actually
used to run the container.
I've reworded the description to hopefully make this behavior clearer.
