I’ve been messing around with podman in Arch and porting my self-hosted services over to it. However, it’s been finicky and I am wondering if anybody here could help me out with a few things.
- Some of my containers aren’t getting properly started up by
podman-restart.serviceon system reboot. I realized they were the ones that depended on my slow external BTRFS drive. Currently its mounted withx-systemd.automount,x-systemd.device-timeout=5so that it doesn’t hang up the boot if I disconnect it, but it seems like Podman doesn’t like this. If I remove the systemd options the containers properly boot up automatically, but I risk boot hangs if the drive ever gets disconnected from my system. I have already triedx-systemd.before=podman-restart.serviceandx-systemd.required-by=podman-restart.service, and even tried increasing the device-timeout to no avail.
When it attempts to start the container, I see this in journalctl:
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: libpod-742b4595dbb1ce604440d8c867e72864d5d4ce1f2517ed111fa849e59a608869.scope: Deactivated successfully.
Aug 27 21:15:46 arch-nas conmon[3124]: conmon 742b4595dbb1ce604440 : runtime stderr: error stat'ing file `/external/share`: Too many levels of symbolic links
Aug 27 21:15:46 arch-nas conmon[3124]: conmon 742b4595dbb1ce604440 : Failed to create container: exit status 1
- When I shutdown my system, it has to wait for 90 seconds for
libcrunandlibpod-conmon-.scopeto timeout. Any idea what’s causing this? This delay gets pretty annoying especially on an Arch system since I am constantly restarting due to updates.
All the containers are started using docker-compose with podman-docker if that’s relevant.
Any help appreciated!
EDIT: So it seems like podman really doesn’t like systemd automount. Switching to nofail, x-systemd.before=podman-restart.service seems like a decent workaround if anyone’s interested.
Podman is fully open source, there is podman desktop
I just wish podman-compose wasn’t so scuffed. I submitted a PR about some garbage months ago and it just seems dead.
You’re supposed to use podman kube play instead of that
What happens if you use regular docker-compose but with podman-docker? I’ve gotten better results with that.
It just bothers me that I have to use a tool outside of the ecosystem for that. Doesn’t it also behave differently though? Like doesn’t it assume everything is root when you use the socket required for docker-compose?
Yes, I think it does, but thats how docker-compose works with docker anyways so it’s a closer experience. I think if you’re using docker-compose files you sorta want that docker-like experience no?
I get where you’re coming from though. It would be nice to run docker-compose files completely rootless with podman-compose.
Eh, I don’t mind learning a new config if the tool requires it. I just want to define run commands in yaml and have it auto generate pods and startup scripts.
You need to mention muayyad-alsadi, because the only one who maintain it now seems only him. Just keep mentioning, and he will review the PR.