quadlet does not generate service from .container files in `/etc/containers/systemd/` on boot about podman HOT 6 CLOSED

I gave up.

from podman.

We have seen issues with apps failing because the start before the network stack is up. If you added requirements to make sure the network stack is up, your redis server might work better.

from podman.

I was able to reproduce this issue with both 4.6.1 and 4.9.4 and it does seem related to the symlink.

I'm looking into this issue, but fixes will only be part of future versions. So, for 4.6.x the solution is not to use symlinks.

from podman.

@Coachonko Are you sure that manually running systemctl daemon-reload generates the service? For me it does not work when the symlink is in /etc/containers/systemd

from podman.

After further testing, I found that the success or failure of the procedure does depend on the location of the actual file and only for system services.
When the actual file was under /tmp and linked from /etc/containers/systemd, Quadlet failed to open the file resulting in open /etc/containers/systemd/test-redis.container: no such file or directory (I had to make some changes to the code to see the print). However, storing the file under ~/tmp/ with a similar symlink worked.
Can you please elaborate on where the actual file is stored?

from podman.

Thank you for trying to reproduce the issue, I had already given up, I do not have the project set up any longer so I cannot attempt to repro it any more.
The file used to be in my user's home dir, in this exact path: /home/coachonko/Documents/projects/containers/deploy/nginx.container
I did do a symbolic link of the nginx.container file to the /etc/containers/systemd/ directory.
systemctl daemon-reload did generate the service.

If I will need to use containers again on this version of podman I will use hard file copies and stay away from symbolic links.

from podman.