Systemd 254 released and now has a new soft-reboot option:
* A new "soft-reboot" mechanism has been added to the service manager.
A "soft reboot" is similar to a regular reboot, except that it
affects userspace only: the service manager shuts down any running
services and other units, then optionally switches into a new root
file system (mounted to /run/nextroot/), and then passes control to a
systemd instance in the new file system which then starts the system
up again. The kernel is not rebooted and neither is the hardware,
firmware or boot loader. This provides a fast, lightweight mechanism
to quickly reset or update userspace, without the latency that a full
system reset involves. Moreover, open file descriptors may be passed
across the soft reboot into the new system where they will be passed
back to the originating services. This allows pinning resources
across the reboot, thus minimizing grey-out time further. This new
reboot mechanism is accessible via the new "systemctl soft-reboot"
command.>
You must log in or # to comment.
If I’m understanding this right it seems like a good fast way to test that services start up properly without doing a full reboot so that’s pretty nice.
Wow, this seems really useful! What a neat feature.
Hard-reboots are no longer required on Silverblue when installing or upgrading packages (besides kernel) through
rpm-ostree. Arguably one should only sparingly rely onrpm-ostreefor installing packages. But it’s great to have access to soft-reboot when setting up a new system.Also:
When the system hibernates, information about the device and offset used is now written to a non-volatile EFI variable. On next boot the system will attempt to resume from the location indicated in this EFI variable. This should make hibernation a lot more robust, while requiring no manual configuration of the resume location.
- Support for System V service scripts is now deprecated and will be removed in a future release. Please make sure to update your software now to include a native systemd unit file instead of a legacy System V script to retain compatibility with future systemd releases.
Why is this being removed?
I wouldn’t use it but it certainly seems handy for a quick hack and also for people who are used to the old ways.
Maintaining legacy options is always maintenance overhead or things you need to work around when implementing new features. I suspect that they’ve concluded that not enough people use it anymore to justify the overhead.
Yeah it’s not like service files are difficult to write. They’re certainly easier than sysv init files
So is this like that windows ‘fast boot’ or whatever it’s called thing?
It is nothing like that. Windows fast boot is just fancy resume from hibernation.
It’s a mix. It hibernates what would be the result of a systemd soft-reboot, before user space starts up again.
Does that mean we will be able to update graphics drivers without a full reboot if the kernel didn’t update?
You could always do that. If you update Mesa, any applications you start after updating will use the new version of Mesa
Oh? I thought I’d at least have to reload a kernel module or something.
Removed by mod
deleted by creator
Near instant? They’ve been extremely slow during the update process for me, at least. I haven’t even layered that many packages, the only reason I can think of is that those few could have pulled a ton of dependencies with them, but it’s still way too slow to me (though I still love the distro for all its other perks).
