soft-reboot and surviving it

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux