Hi, we finished the integration of soft-reboot into openSUSE Tumbleweed and MicroOS (transactional-update), and the major problems except firewalld+podman are solved. Now we only need to do all the "fine tuning". Is there meanwhile any reliable/official way to detect that this was a soft-reboot? This would be very helpful in some cases for post mortem analysis and support. I'm aware of the SoftRebootsCount property in systemd v256, so applications could query that and I assume if the count is >0 it was a soft-reboot? Couldn't test that yet. 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. Is there already some documentation somewhere, what are the limitations or best practices for an application for surviving a soft-reboot? The main task for me currently is, to find out what such an application can do, what will not work, and what they should do in case of a reboot. I saw there is the PrepareForShutdownWithMetadata signal (I didn't got that working, but since it seems to work with busctl, the problem is most likely between chair and keyboard ;) ), but I'm more interested about file descriptors and pipes. Currently stderr will be redirected to journald, but this will of course no longer work after a soft-reboot. While I can adjust my application to use sd_journal_print() instead, errors written by libraries or something else to stderr will go lost or trigger SIGPIPE.. Any ideas on how to solve that? 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)