Quadlet wont start on boot, pasta says "Couldn't set IPv4 route(s) in guest: Invalid argument" #22190
Comments
|
@quietsoviet, thanks for reporting this. Can you please share what addresses ( |
|
I still have my docker-compose while is slowly transition to rootless podman so i have lots of veth* networks and br* 192.168.90 to 94 are docker bridges, as is br with 172.18.0.0. virbr(192.168.1.100) is virt-manager bridge. |
|
As an additional test, is pasta itself (without Podman) able to start on your host and configure network interfaces? You could try simply issuing: and see if it starts, and if the network namespace you're now in has addresses and routes configured (they should approximate |
|
After some time pasta stops giving errors and container will start and able to connect to internet, but only with |
Okay, and is IPv4 set up in the new network namespace (and shell) you're in, now? Can you check with |
|
Given it starts eventually my assumption would be that the host network is not fully set up when the quadlet unit is started. So while pasta is tryting to figure out the interface adrresses/routes it is possible that the settings change at the same time on the host possibly causing issues for pasta. |
|
It trow me in root and this is result |
|
I tried with removing linger, because this is second PC and i have monitor connected to it with autologin. Still pasta isn't finished and containers wont start. Then i added |
Thankfully, that's not actual root ;) but it looks like that -- it's UID 0 in a detached user namespace.
...so, as expected, also if you start pasta manually at some later point it works.
Right, I also think this is essentially the same as #22197. I guess the most obvious solution is to add preconditions to the systemd services so that initial networking setup is guaranteed to be done before quadlet units can start. On the other hand, we might have ways to make pasta more robust, but I don't have a concrete idea yet -- suggestions warmly welcome. |
|
Thank you for replaying i did some scouring on internet and added to my quadlets so they delay on boot and start normaly with no errors. Only in convince is that when i start them manually they delay. But it works in rootless podman. I will close this issue ant thank you for your help |
That is god-tier foot-gun that. That's not resolution, that's a ugly hack that is gonna generate many heisenbugs in the future. We need pasta to wait for the network to be set. |
Thanks for your constructive commentary, Gaël. Note, though, that nobody tried to sell that as a resolution for this issue -- it's simply a workaround. This issue is being tracked as #22197, and that's why this one is closed, it's a duplicate.
This should be done externally, because you have essentially the same issue with any other network mode, including slirp4netns. The container with slirp4netns will start, but until the host network is fully set up, connectivity will be broken, or worse, one might be sending traffic with incomplete firewalling rules or with inconsistent routing. See also systemd/systemd#3312 (comment) -- and mind that contributions, including yours, are warmly welcome. |
No. It's not. It's sloppiness and incompetence. And it's even less acceptable when it's actively used as an excuse not to revert a broken commit. Being referred to as a workaround in different places makes it even worse... But the most appalling part is that no one in this project is apparently capable of simply saying "we've tried, CI/CD does not pass because we have a race condition here, let's postpone the change until the rest of the environment catches up with us". Instead you decided to take the very "constructive" approach to ship known-broken product anyway. BTW, today we decided to renew our Ubuntu Pro licenses and we'll keep using Docker too. As the person pushing Fedora CoreOS and Podman, trust me, I am not pleased at all but that's the consequence of that sloppiness. |
Again: the issue exists with slirp4netns and other network modes, too. It's not about reverting a broken commit. With slirp4netns, containers will start, and users are even less likely to notice about any issue of this sort (speaking of heisenbugs...). Looking at typical systemd units for usage with Docker Compose, I'm fairly sure you would face similar issues with them.
Rest assured that nobody here is knowingly shipping broken things. Continuous integration tests passed because, to reproduce this, you need a setup that makes network initialisation somewhat slow at boot, and that wasn't the case for the test environments at hand. |
stale-locking-app
bot
added
the
locked - please file new issue/PR
Issue Description
Quadlet wont start on boot tried plex, jellyfin and syncthing setting from arch podman wiki. But manualy starts no problems.
And then containers exits with Start request repeated too quickly.
Then i added
StartLimitBurst=0to quadletFocus is on
syncthing-lsio.service: Scheduled restart job, restart counter is at 18.And why is log filled with failed systemd and passt.avx2.After more reading i found about slirp4netns and adding to jellyfin
Network=slirp4netnsand removingStartLimitBurst=0It started normaly with no errors in log
Steps to reproduce the issue
Steps to reproduce the issue
StartLimitBurst=0starts automatically with lots of errorsNetwork=slirp4netnsstarts auto with no errors in logsDescribe the results you received
Quadlet wont start automaticly but manualy works without changing default settings. Some pasta errors and containers exit after 6 trys
Describe the results you expected
Containers just starting.
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
Bare metal PC
Additional information
I am sorry if this post is bad and or redundant, cant find on google my problem but was able to mitigate it somewhat by myself so maybe it will help someone. If you need more information just ask.
The text was updated successfully, but these errors were encountered: