Remove `LimitNOFILE` from `containerd.service` to rely on the systemd v240 implicit default of `1024:524288`. On supported platforms with systemd prior to v240, packagers will patch the service with an explicit `LimitNOFILE=1024:524288`.
- `1024` soft limit is an implicit default, avoiding unexpected breakage. Software that needs a higher limit should request to raise the soft limit for its process.
- `524288` hard limit is an implicit default since systemd v240 and is adequate for most processes (_half of the historical limit from `fs.nr_open` of `1048576`_), while 4096 is the implicit default from the kernel (often too low).
- The hard limit may not exceed `fs.nr_open` (_which a value of `infinity` will resolve to_). On most systems with systemd v240 or newer, this will resolve to an excessive size of 2^30 (over 1 billion).
- When set to `infinity` (usually as the soft limit) software may experience significantly increased resource usage, resulting in a performance regression or runtime failures that are difficult to troubleshoot.
Signed-off-by: Brennan Kinney <5098581+polarathene@users.noreply.github.com>
According to the systemd documentation, `infinity` can be used for all limits;
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Process%20Properties
> Resource limits may be specified in two formats: either as single value to set a
> specific soft and hard limit to the same value, or as colon-separated pair soft:hard
> (...) Use the string infinity to configure no limit on a specific resource.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When running containerd inside LXC, due to systemd being unable to execute
`modprobe overlay` inside the container (module is already loaded in host kernel).
This patch adds a `-` prefix to the `ExecStartPre` command, so that failures
are ignored, and the service can start as usual.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
