[systemd-devel] soft-reboot and surviving it

Thorsten Kukuk kukuk at suse.com
Fri Apr 19 11:50:16 UTC 2024


On Fri, Apr 19, 2024 at 11:48 AM Luca Boccassi <luca.boccassi at gmail.com> wrote:
> On Fri, 19 Apr 2024 at 10:30, Thorsten Kukuk <kukuk at suse.com> wrote:

> > And now I started looking into how services can survive the
> > soft-reboot. I know the FOSDEM talk from Luca about this topic, but I
> > don't like to move the application into another image, as this would
> > only move the update problem to a different level and not solve it. So
> > I'm currently playing with it to find out if there isn't a better
> > option, especially with btrfs.

> It really needs to be a separate filesystem from a separate image, any
> ties back to the host OS and the service will be hopefully correctly
> stopped, or worse it will not be detected and it will leak the old
> filesystem, which means you'll silently leak memory, mounts, etc. I
> would strongly recommend to avoid fighting against this, and instead
> spend time solving the root cause.

I agree that you have a problem if you use something like a partition
A/B setup, where in worst case, you start from A, soft-reboot to B,
updates A and latest in this moment you will overwrite the code of the
running application.
I'm not sure if this is really a problem with btrfs and subvolumes, as
they stay mounted anyways in our setup.
I hope I find the time to discuss this next week with our btrfs developers.

> The best solution really is to figure out why there's a executable
> from the host OS permanently running in the podman container cgroup
> (what does it do, why it is necessary, why does it need to always run,
> etc), and try to refactor that away. Make it started on demand for
> example.

That's conmon, no idea why it needs to continue to run. But this would
only solve the problem for podman, I have several other use cases in
mind where containers are not involved.

  Thanks,
    Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461
Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB
36809, AG Nürnberg)


More information about the systemd-devel mailing list