[systemd-devel] soft-reboot and surviving it
Thorsten Kukuk
kukuk at suse.com
Fri Apr 19 08:29:22 UTC 2024
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)
More information about the systemd-devel
mailing list