On Fri, Apr 19, 2024 at 11:48 AM Luca Boccassi <luca.boccassi@xxxxxxxxx> wrote: > On Fri, 19 Apr 2024 at 10:30, Thorsten Kukuk <kukuk@xxxxxxxx> 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)