sdnotify (READY) support

[j1nx]

I am in progress (learning howto) to create and run the containers fully under systemd by utilizing the quadlets system which is part of Podman >4.4

One of the benefits of it is to use the sdnotify system to let systemd know when a started container is fully loaded and ready.

"--sdnotify=container" instead of "--sdnotify=conmon"

For this to work, we need to use the systemd wrappers as start entry point within the containers. As there is no downside of using the wrappers while not using the sdnotify system itself, I would like to ask to make it the default entry point such that I can just pull the images from the registry instead of building them myself.

[goldyfruit]

I'll have to check but I don't think sdnotify is supported by Docker.

[goldyfruit]

Did some research and indeed, --sdnotify is not supported by Docker.

--sdnotify seems to be by default set with container.

podman inspect ovos_stt_fasterwhisper | jq .[].Config.sdNotifyMode
"container"

Did you run as well the podman generate systemd command?

podman generate systemd --new -n -f --start-timeout 600 ovos_stt_fasterwhisper

[j1nx]

For podman systemd integration having the ovos service reporting back that it is ready to rock and roll, we need to include the systemd wrappers within the containers and change the entry points to use them.

https://github.com/OpenVoiceOS/ovos-buildroot/tree/5c7af8b05892206846ae06adb3478f1df620bf6b/buildroot-external/rootfs-overlay/base/usr/libexec

You need the mycroft-systemd-* files.

---

As example for the messagebus service, instead of having the ENTRYPOINT = "ovos-messagebus" we will have to change the entry point to; calling that wrapper file "mycroft-systemd-messagebus".

It does the same, starting the messagebus service, houwever really sending the sdnotify READY back to the system.

That way we can use the --sdnotify=container podman flag to let systemd know the service itself is fully ready, instead of the container has been launched. (the container could be launched but system will otherwise not know if the messagebus itself is also fully started/ready)

[goldyfruit]

I think these files should be part of a Python package on PyPi and renamed to ovos.

What do you think?

[builderjer]

all of the systemd hook files on PyPi? That would make things easy

[j1nx]

Agree! Will ping @JarbasAl for when he is back from holidays.

[JarbasAl]

all of the systemd hook files on PyPi? That would make things easy

i dont mind adding those entrypoints to the repos, but sdnotify should not be a hard dependency (as we want to support non systemd services too), either add a new entrypoint or make the sdnotify import optional in the main entrypoints (use it if its there else ignore)

[builderjer]

That would probably be the quickest way to make it optional for sure.

[goldyfruit]

all of the systemd hook files on PyPi? That would make things easy

i dont mind adding those entrypoints to the repos, but sdnotify should not be a hard dependency (as we want to support non systemd services too), either add a new entrypoint or make the sdnotify import optional in the main entrypoints (use it if its there else ignore)

I think we should have a dedicated repo for these files.

[j1nx]

I once made this; https://github.com/j1nx/mycroft-systemd

I could transfer it so we can bump/ change the files.

[goldyfruit]

I once made this; https://github.com/j1nx/mycroft-systemd

I could transfer it so we can bump/ change the files.

Yeah and maybe build a PyPi package based on specific directory.

[builderjer]

That's what I was thinking when I looked also.

[j1nx]

Here we go!

https://github.com/OpenVoiceOS/ovos-systemd

No clue about PyPi packaging but gave access to any distro admin, so we should be able to get it up to date.

[j1nx]

@builderjer Did you started the work on the systemd wrappers already?

I just discovered that for the auto-update/rollback feature of podman it actually needs the "sdnotify=container" flag as the rollback uses it to determine if the update was succesfull or not.

[j1nx]

Not entirely true anymore; https://github.com/containers/podman/pull/19353

Looks like we can also use the healthy checks now to report back to systemd. Will do some testing with it.

[builderjer]

I did start on it, but cloned from ovos repo instead of forking my own. Now I see I dont have permissions there

[goldyfruit]

@j1nx what happens if systemd is not running on the system (like SysV is running instead)?

[goldyfruit]

I'll close this issue as for now this will not be implemented.