Does podman have a hard requirement on systemd?

[drawks]

Before I open an issue, I just want to calibrate my expectations. I don't see anywhere obvious that podman has a hard requirement on systemd. However I'm finding that several aspects of podman, especially when running rootless, seem to fail when run without a functional systemd. To be clear, even when running podman commands with --cgroup-manager=cgroupfs various aspects of podman seem to fail with errors like DEBU[0000] Failed to add podman to systemd sandbox cgroup: dial unix /run/user/0/bus: connect: permission denied and ERRO[0371] failed to move the rootless netns slirp4netns process to the systemd user.slice: dial unix /run/user/0/bus: connect: permission denied. Also baked in integrations with aardvark-dns seem to have similar hardcoded dependencies/expectations that you have a functional systemd:

[DEBUG netavark::dns::aardvark] start aardvark-dns: ["systemd-run", "-q", "--scope", "--user", "/usr/libexec/podman/aardvark-dns", "--config", "/tmp/containers-user-989/containers/networks/aardvark-dns", "-p", "53", "run"]
Failed to connect to bus: No such file or directory

So, I guess what I'm getting at is that it'd be great if someone could point me at something which documents definitively what is expected to work/not work when using podman without systemd.

if it matters my testing thus far has been on podman 4.4.1 with aardvark-dns 1.5.0 on top of Almalinux 9.2 (5.14.0 kernel)

edit:
containers/netavark#436 is a related MR/issue in the netavark project

[rhatdan]

Perhaps you could try --network=host, and see if you can get containers working that way.
Podman has been ported to run on freebsd, so I guess that it does not require systemd. Most people who run it though work on systemd systems, and so it has not been tested well on non systemd systems.

[rhatdan]

BTW You can set both of those options permanently in containers.conf file.

[Luap99]

Why are you trying to run without systemd on AlmaLinux?
If you properly log into the user you should get a systemd user session and these problem go away. This looks like to me you use su/sudo to switch users instead of correctly logging in, see https://github.com/containers/podman/blob/main/troubleshooting.md#solution-28

[drawks]

The why is sort of an aside.

Yes I know how to run podman with systemd user sessions. And yes I've already read a lot of documentation including the guide you've linked to. I'm not asking for help troubleshooting a broken system, I'm simple asking when running podman with --cgroup-manager=cgroupfs why there seems to still be dependencies on systemd machinery. Is that an intentional? Is it a bug? If it is intentional should it be more specifically called out in the documentation? If the operator requests a cgroup manager that isn't systemd does podman make that choice known in the APIs for pluggable subsystems?

edit: When I say "the why is an aside", I mean I happen to have noticed this incongruity while on an Alma 9 host, but I could just as easily be on another distro that uses systemd for init 1, but has disabled systemd users sessions (see: https://bugzilla.redhat.com/show_bug.cgi?id=2041815). I can think of at least a handful of reasons why a user would be on a host which /HAS/ systemd installed or in use in some way but does not or cannot use it in the way that podman (and perhaps its plugins) seemingly expects it to be available in-spite of the operator indicating that they do not wish to use systemd by explitcly setting the cgroup_manager to cgroupfs.

[Luap99]

From the man page:

The CGroup manager to use for container cgroups

I see no reason the interpret this as please do not use systemd. It means do not use it for container cgroup creation!
I mean sure it makes sense to read like this for podman in a setup like yours I guess but it doesn't necessarily means that is what everybody wants.

The main issue with systemd is that it can kill the long running processes in background if we do not move them to their unit/scope. Thus as rootless you quickly end up without function networking and if the pause process is killed you quickly run into impossible to debug namespacing issues.

Now of course that does not mean that it won't work if we don't move them just that things are much more likely to break is obscure ways. If it is somehow given that these processes are not killed without having a user session then things may just work fine and I tend to agree that we can ignore failures.

@giuseppe WDYT?

[drawks]

The main issue with systemd is that it can kill the long running processes in background if we do not move them to their unit/scope. Thus as rootless you quickly end up without function networking and if the pause process is killed you quickly run into impossible to debug namespacing issues.

Unless I'm mistaken, you're referring to systemd reaping processes which are run within the user scope when the user scope is stopped on logout when the user is not marked to linger. If however a non-root rootless podman is forked without ever being part of a systemd user scope then this entire rube goldberg of events doesn't happen and doesn't require any additional care and feeding.

I see no reason the interpret this as please do not use systemd. It means do not use it for container cgroup creation!
I mean sure it makes sense to read like this for podman in a setup like yours I guess but it doesn't necessarily means that is what everybody wants.

That is fair and I suppose the knock on question I'd have is to then clarify what would be the use case where you'd not want to delegate the cgroup management to systemd, but would want all of the various other systemd specific behaviors to opportunistically succeed in the case that a systemd dbus socket happens to be available and listening?

And I guess the ultimate question I have goes back to my original question, slightly reworded with some information gleened from the conversation thus far.

"Since podman doesn't have a hard requirement on systemd, should it have a configuration option which allows an operator to explicitly specify that they would like for systemd integration to be on/off/auto?"

Such an option could have the effect of short circuiting heuristics and also to influence whether failures to use systemd features are raised as critical errors or not. Likewise such an explicit config handled at the top level would allow for the choice to be propagated through the plugin API to avoid each plugin which /may/ use systemd from seperately implementing their own heuristic or operating in a fashion contrary to the operator's declared intent.

[gdragon-git]

I am a VPS user who has been provided Linux access on a system that restricts systemd. I would love to run podman and configure it to explicitly not use systemd at all, if possible.

[rhatdan]

There are settings in containers.conf that allow you to remove need for systemd, I believe, could be limiting in rootless mode.

[rhatdan]

#cgroup_manager = "cgroupfs"
#events_logger = "file"