search

kairos-io / kairos

:penguin: The immutable Linux meta-distribution for edge Kubernetes.
https://kairos.io
Apache License 2.0
1.07k stars 93 forks source link

kairos.service in activating status forever #2665

Closed Itxaka closed 1 month ago

Itxaka commented 2 months ago

Kairos version: master

CPU architecture, OS, and Version: all

Describe the bug during livecd boot the kairos.service never moves to started, it keeps always in starting. That means that the service is not correctly configured as the proper type is not set to let systemd know that the service is running. This means that systemd will never enter in a proper status and will think the system is in State: starting forever. We migth need to fix this so the system is proper set in case somebody want to check for system services failures or status as health checks

[root@fedora ~]# systemctl status kairos
● kairos.service - kairos installer
     Loaded: loaded (/etc/systemd/system/kairos.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: activating (start) since Wed 2024-06-26 09:47:43 UTC; 21min ago
   Main PID: 936 (kairos-agent)
      Tasks: 11 (limit: 27766)
     Memory: 89.2M (peak: 92.7M)
        CPU: 387ms
     CGroup: /system.slice/kairos.service
             ├─ 936 /usr/bin/kairos-agent install
             └─1163 /bin/sh

To Reproduce start lviecd, check systemctl status output

Expected behavior

status to be active

Logs

Additional context

Itxaka commented 2 months ago

oh yeah, if you restart the service you get a panic and then the installer starts again, also should be fixed by gathering the sigint signal and properly exiting?

Itxaka commented 2 months ago

Changing the service type to "simple" makes it work as expected.

We could also set it to notify and make the agent send a notification back via DBUS once started so systemd confirms that this is working as expected

Behavior of notify is similar to exec; however, it is expected that the service sends a "READY=1" notification message via [sd_notify(3)](https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html#) or an equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after this notification message has been sent. If this option is used, NotifyAccess= (see below) should be set to open access to the notification socket provided by systemd. If NotifyAccess= is missing or set to none, it will be forcibly set to main.
mauromorales commented 2 months ago

I was experiencing a similar issue when running via qemu-amd64 on the terminal, if I use the exact same image on virutal machine manager, i have no issues