dumpconf: Don't run the service in LXC

[rbalint]

It just fails to start in unprivileged containers

Signed-off-by: Balint Reczey balint.reczey@canonical.com

[xnox]

This results in Ubuntu lxd containers to come up degraded by default, which is not nice. And I do agree that dumpconf doesn't make sense to run inside containers.

I think one can even specify it as:

ConditionVirtualization=!container

As this service only makes sense on LPAR, z/VM, kvm hosts and not inside container guests.

To only start this service on LPARs and z/VMs, but not in any other

To avoid attempting to start dumpconf under

[eaibmz]

And what about a privileged container ? It could probably make sense to run dumpconf inside a privileged container that would be able to setup dump parameters.

[rbalint]

And what about a privileged container ? It could probably make sense to run dumpconf inside a privileged container that would be able to setup dump parameters.

Privileged containers are quite rare and most likely this service should run on the host IMO. This change can be overridden in local configuration if this is really needed.

[xnox]

And what about a privileged container ? It could probably make sense to run dumpconf inside a privileged container that would be able to setup dump parameters.

in normal / regular setups that does not make sense.

It only makes sense on systems that have no host at all, where all the "host" config is done from a container too..... then such a system-control container will do lots of interesting things like rebooting the host. KubesOs / CoreOS come to mind, which would then need to adjust this. If they rely on this. But that's very niche and specific to those deployments. The vast majority of stock linux distors (ubuntu/rhel/suse) would not want dumpconf to run from a container by default (priviledged, or not).

[eaibmz]

I'm not familiar with LXC but how come a system service is executed inside a container ? With Docker, it is commonplace to run a single application inside a container and running system services like systemd is considered a bad practice. How come a system service like dumpconf is being executed inside a container ?

[xnox]

I'm not familiar with LXC but how come a system service is executed inside a container ? With Docker, it is commonplace to run a single application inside a container and running system services like systemd is considered a bad practice. How come a system service like dumpconf is being executed inside a container ?

docker is usually a single process container. However, one can also run systemd as the "single process" and start a fully functional system, all the way to multi-user.target.

lxc is a system container. I.e. you may know these type of container management solutions as systemd-nspawn, virtuozzo, openvz, VPS. By default it does launch /sbin/init and start all the services and boots to multi-user.target. One cannot usually modprobe new kernels or affect /dev /sys of the host, but one does have ssh.service / apache2.service and all the usual things running like on a normal system. Meaning all the services are running.

[xnox]

lxd is available on s390x, one can install as a snap from the snapstore and launch images as one likes.

See https://linuxcontainers.org/lxd/getting-started-cli/

There are ubuntu images published for s390x as ubuntu:focal for example, but there are also s390x images published at the images: endpoint for fedora debian alpine all for s390x, and multiple releases.

I often use lxd to quickly spin up a "fedora" container to compare how things are done for s390x there vs Ubuntu, to reproduce / compare bugs, test toolchains, etc.

[frank-heimes]

This is an attempt to revitalize this 'cold case', so I'm trying to re-cap:

I guess we can probably agree that:

• the dump service must be turned off in case of non-privileged containers, which is the vast majority of cases, since it otherwise just fails
• that it's even difficult to find a meaningful cases where it might make sense to have it enabled with privileged containers - where the service at least no longer fails to start, (So there might be cases, but these are the vast minority!)
• and that the service is really meant to run on the host.

In case yes, a good default is obviously one that is good for the majority of cases, hence best practice is surely to have: ConditionVirtualization=!lxc in as default.

I think it just doesn't make sense having a default value that addresses just exceptional cases.

If such a rare case, where it really need to be changed occurs, it'll be a special case, that is then highly likely treated by an advanced user who probably knows what he/she is doing (and not vice versa).

Just m 2-cents.

[hoeppnerj]

This got lost again, I'll take the PR and even change it to !container as suggested.

[frank-heimes]

That would be great - thx!