This will make it easier to track specifically where queries are being
made from (assuming a `log_line_prefix` that includes `%a` in the
postgres configuration).
The manual mentions how "[config and pkgs] are explained later". Added a link
to where they are explained, and a hint pointing to the NIX_PATH variable.
the nix store may contain hardlinks: derivations may output them
directly, or users may be using store optimization which automatically
hardlinks identical files in the nix store.
The presence of these links are intended to be a 'transparent'
optimization. However, when creating a squashfs image, the image
will be different depending on whether hard links were present
on the filesystem, leading to reproducibility problems.
By passing '-no-hardlinks' to mksquashfs the files are stored
as duplicates in the squashfs image. Since squashfs has support
for duplicate files this does not lead to a larger image.
For more details see
https://github.com/NixOS/nixpkgs/issues/114331
- Actually use the zfsSupport option
- Add documentation URI to lxd.service
- Add lxd.socket to enable socket activatation
- Add proper dependencies and remove systemd-udev-settle from lxd.service
- Set up /var/lib/lxc/rootfs using systemd.tmpfiles
- Configure safe start and shutdown of lxd.service
- Configure restart on failures of lxd.service
- Use --netlink to avoid systemd-udev-settle[1]
- Run daemon in foreground which is preferred with systemd
- Add unit documentation
- Write ExecStart directly, no need for a script
[1]: 52bbd2b80b
The sysfs file /sys/kernel/mm/ksm/run seems to be available as soon as
the kernel has started, so no point in waiting for udev to "settle". If
for some reason it doesn't, we let the unit fail explicitly.
To make it easier to start and stop all GitLab services, introduce
`gitlab.target` which wants all services (meaning they will start with
it) and which all services are part of (meaning they will stop with
it).
Make the config initialization script run in gitlab.service's PreStart
section into two new services, `gitlab-config.service` and
`gitlab-db-config.service`. Other services can then depend on the
config scripts they need instead of unnecessarily depending on
`gitlab.service`. This makes the reason for the configured service
dependencies much clearer and should also reduce the restart time of
the `gitlab` service quite a lot, when triggered manually.
Also, set up stricter service dependencies, using `bindsTo`, to ensure
that if a service fails or is stopped, its dependants are also
stopped. For example, if we're using the `postgresql` service and it's
stopped, `gitlab.service` and `gitlab-sidekiq.service`, which depend on
it to function, should also be stopped.
Launching a container with a private network requires creating a
dedicated networking interface for it; name of that interface is derived
from the container name itself - e.g. a container named `foo` gets
attached to an interface named `ve-foo`.
An interface name can span up to IFNAMSIZ characters, which means that a
container name must contain at most IFNAMSIZ - 3 - 1 = 11 characters;
it's a limit that we validate using a build-time assertion.
This limit has been upgraded with Linux 5.8, as it allows for an
interface to contain a so-called altname, which can be much longer,
while remaining treated as a first-class citizen.
Since altnames have been supported natively by systemd for a while now,
due diligence on our side ends with dropping the name-assertion on newer
kernels.
This commit closes#38509.
systemd/systemd#14467systemd/systemd#17220https://lwn.net/Articles/794289/