Uyuni 2024.10 doesn't autostart once container is started after reboot

[stdevel]

Problem description

Once the container is started, e.g. after a system reboot, the application isn't started automatically. The podman ps output shows Unhealthy (starting). In order to get the application up and running, the following commands are required:

# mgrctl term
# spacewalk-service start

Steps to reproduce

1. Reboot server, e.g. after installing patches
2. Check podman ps output, service is in "unhealthy (starting)" state
3. Run mgrctl term to enter the container and check application status with spacewalk-service status. The appropriate services are inactive.

Uyuni version

# rpm -qa|grep -i uyuni
uyuni-storage-setup-server-5.1.1-240900.2.1.uyuni4.x86_64
mgrctl-5.1.2-241000.1.1.uyuni5.x86_64
mgradm-5.1.2-241000.1.1.uyuni5.x86_64
mgradm-bash-completion-5.1.2-241000.1.1.uyuni5.noarch
mgrctl-bash-completion-5.1.2-241000.1.1.uyuni5.noarch
spmga01i:~

#  zypper lr
Repository priorities are without effect. All enabled repositories share the same priority.
 
# | Alias                                         | Name                                                                                | Enabled | GPG Check | Refresh
--+-----------------------------------------------+-------------------------------------------------------------------------------------+---------+-----------+--------
1 | repo-debug                                    | Leap Micro Debug Repository                                                         | No      | ----      | ----
2 | repo-main                                     | Leap Micro Main Repository                                                          | Yes     | (r ) Yes  | Yes
3 | repo-sle-update                               | SLE Micro Update Repository                                                         | Yes     | (r ) Yes  | Yes
4 | repo-source                                   | Leap Micro Source Repository                                                        | No      | ----      | ----
5 | systemsmanagement_Uyuni_Stable_ContainerUtils | Utilities for managing Uyuni containers (openSUSE_Leap_Micro_5.5)                   | Yes     | (r ) Yes  | No
6 | systemsmanagement_Uyuni_Stable_Patches        | Project used to release critical patches between releases (openSUSE_Leap_Micro_5.5) | Yes     | (r ) Yes  | No

# cat /etc/os-release
NAME="openSUSE Leap Micro"
VERSION="5.5"
ID="opensuse-leap-micro"
ID_LIKE="suse opensuse opensuse-leap suse-microos"
VERSION_ID="5.5"
PRETTY_NAME="openSUSE Leap Micro 5.5"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap-micro:5.5"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:LeapMicro"
LOGO="distributor-logo-LeapMicro"

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.

[santeri3700]

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

[stdevel]

Hi @santeri3700, thanks for pointing out! 🎉

Some of those symlinks were actually broken and setting the state you mentioned did the trick.

[santeri3700]

Nice! This bug is probably already fixed with uyuni-project/uyuni-tools#480 so newer migrations shouldn't have the issue (if you have recent enough mgradm version).