Add json file caching for systemd detection results

[youurayy]

Closes #2108

Signed-off-by: Juraj Vitko [email protected]

[cyphar]

What happens if the system gets updated to a new systemd version, such that the cached values are incorrect (at least on openSUSE, neither /var/cache nor /tmp are on a tmpfs)? I'm also slightly concerned about the code which handles the cache file, but we first need to have a solution for invalidation.

[youurayy]

• yes ideally we don't write to an actual filesystem - I'm open to all suggestions
• systemd upgrade: we could add a timestamp into the json file and invalidate every so often

Another (and fast) way of checking systemd capabilities would be to simply ask the systemd binary for a --version, and also somehow determine if this is a RHEL systemd, and then use that combined info to establish a) whether this is a new-enough systemd, b) whether this is an older but backported RHEL systemd, c) neither.

[filbranden]

Quite frankly, we should simply drop these three checks.

• hasStartTransientUnit and hasStartTransientSliceUnit: Anything new enough to run runc and libcontainer will have a systemd that supports this. Even systemd v219 from RHEL 7 has this. Something older than that, at this point, is utterly broken.
• hasDelegateSlice: Newer systemd doesn't support this, but without setting this, everything works fine. So why would we want to set it on older systemd? Not to mention this never really did much while systemd allowed it.

Let's just drop this?

[filbranden]

See #2117 for a PR dropping these checks. It passes tests with RUNC_USE_SYSTEMD=1.

[mrunalp]

This can be closed since #2117 is merged.