Closed stdevel closed 1 hour ago
Do you happen to have broken, misconfigured or missing symlinks in /etc/systemd/system/multi-user.target.wants/
within the container (in etc-systemd-multi
volume)? I had to manually fix sssd.service and clean up some residual units related to a custom backup agent on the old server after migration from 2024.08 (RPM).
This is how my fresh and healthy 2024.10 (Podman) test environment looks like:
# mgrctl exec -- ls -la /etc/systemd/system/multi-user.target.wants/
total 11
drwxr-xr-x. 2 root root 20 Dec 3 11:25 .
drwxr-xr-x. 8 root root 3 Dec 3 11:24 ..
lrwxrwxrwx. 1 root root 39 Aug 16 15:01 apache2.service -> /usr/lib/systemd/system/apache2.service
lrwxrwxrwx. 1 root root 52 Jul 19 14:26 billing-data-service.service -> /usr/lib/systemd/system/billing-data-service.service
lrwxrwxrwx. 1 root root 40 Aug 16 15:01 cobblerd.service -> /usr/lib/systemd/system/cobblerd.service
lrwxrwxrwx. 1 root root 43 Jul 19 13:02 kbdsettings.service -> /usr/lib/systemd/system/kbdsettings.service
lrwxrwxrwx. 1 root root 39 Jul 19 14:25 postfix.service -> /usr/lib/systemd/system/postfix.service
lrwxrwxrwx. 1 root root 42 Dec 3 11:25 postgresql.service -> /usr/lib/systemd/system/postgresql.service
lrwxrwxrwx. 1 root root 56 Jul 19 14:26 prometheus-node_exporter.service -> /usr/lib/systemd/system/prometheus-node_exporter.service
lrwxrwxrwx. 1 root root 40 Jul 19 13:02 remote-fs.target -> /usr/lib/systemd/system/remote-fs.target
lrwxrwxrwx. 1 root root 42 Aug 16 15:01 rhn-search.service -> /usr/lib/systemd/system/rhn-search.service
lrwxrwxrwx. 1 root root 39 Jul 19 14:25 rsyslog.service -> /usr/lib/systemd/system/rsyslog.service
lrwxrwxrwx. 1 root root 40 Aug 16 15:01 salt-api.service -> /usr/lib/systemd/system/salt-api.service
lrwxrwxrwx. 1 root root 43 Aug 16 15:01 salt-master.service -> /usr/lib/systemd/system/salt-master.service
lrwxrwxrwx. 1 root root 40 Aug 16 15:01 spacewalk.target -> /usr/lib/systemd/system/spacewalk.target
lrwxrwxrwx. 1 root root 36 Jul 19 14:26 sssd.service -> /usr/lib/systemd/system/sssd.service
lrwxrwxrwx. 1 root root 42 Aug 16 15:01 taskomatic.service -> /usr/lib/systemd/system/taskomatic.service
lrwxrwxrwx. 1 root root 50 Jul 19 14:26 timezone_alignment.service -> /usr/lib/systemd/system/timezone_alignment.service
lrwxrwxrwx. 1 root root 38 Aug 16 15:01 tomcat.service -> /usr/lib/systemd/system/tomcat.service
lrwxrwxrwx. 1 root root 38 Jul 19 14:25 wicked.service -> /usr/lib/systemd/system/wicked.service
Hi @santeri3700, thanks for pointing out! 🎉
Some of those symlinks were actually broken and setting the state you mentioned did the trick.
Nice! This bug is probably already fixed with https://github.com/uyuni-project/uyuni-tools/pull/480 so newer migrations shouldn't have the issue (if you have recent enough mgradm version).
Problem description
Once the container is started, e.g. after a system reboot, the application isn't started automatically. The
podman ps
output showsUnhealthy (starting)
. In order to get the application up and running, the following commands are required:Steps to reproduce
podman ps
output, service is in "unhealthy (starting)" statemgrctl term
to enter the container and check application status withspacewalk-service status
. The appropriate services are inactive.Uyuni version
Uyuni proxy version (if used)
No response
Useful logs
No response
Additional information
I migrated from 2024.07 (RPM) to 2024.10 (Podman).
I re-enabled autostart for the Uyuni services (
spacewalk-service enable
), but nothing has changed.