Systemd 254 - now with soft-reboot

Systemd 254 released and now has a new soft-reboot option:


<span style="color:#323232;">    * A new "soft-reboot" mechanism has been added to the service manager.
</span><span style="color:#323232;">      A "soft reboot" is similar to a regular reboot, except that it
</span><span style="color:#323232;">      affects userspace only: the service manager shuts down any running
</span><span style="color:#323232;">      services and other units, then optionally switches into a new root
</span><span style="color:#323232;">      file system (mounted to /run/nextroot/), and then passes control to a
</span><span style="color:#323232;">      systemd instance in the new file system which then starts the system
</span><span style="color:#323232;">      up again. The kernel is not rebooted and neither is the hardware,
</span><span style="color:#323232;">      firmware or boot loader. This provides a fast, lightweight mechanism
</span><span style="color:#323232;">      to quickly reset or update userspace, without the latency that a full
</span><span style="color:#323232;">      system reset involves. Moreover, open file descriptors may be passed
</span><span style="color:#323232;">      across the soft reboot into the new system where they will be passed
</span><span style="color:#323232;">      back to the originating services. This allows pinning resources
</span><span style="color:#323232;">      across the reboot, thus minimizing grey-out time further. This new
</span><span style="color:#323232;">      reboot mechanism is accessible via the new "systemctl soft-reboot"
</span><span style="color:#323232;">      command.>
</span>
r0b0,

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.

CloverSi,

Wow, this seems really useful! What a neat feature.

Atemu,
@Atemu@lemmy.ml avatar
  • 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.

dr_robot,
@dr_robot@kbin.social avatar

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.

PM_ME_UR_PCAPS,

Yeah it’s not like service files are difficult to write. They’re certainly easier than sysv init files

Chais, (edited )
@Chais@sh.itjust.works avatar

Does that mean we will be able to update graphics drivers without a full reboot if the kernel didn’t update?

treadful,
@treadful@lemmy.zip avatar

I don’t think any graphics drivers run in user-space, so probably not.

garam,
@garam@lemmy.my.id avatar

Kernel space…

GNU Hurd… Hurt… 😂

Chais,
@Chais@sh.itjust.works avatar

True. Dammit.

Backslash,

Yes they do, Mesa being one. Only the close to the metal stuff and Kernel-DRM is handled in kernel space, most of the heavy stuff is done in user space.

treadful,
@treadful@lemmy.zip avatar

Where’s the line you’re drawing? And what would be the “heavy stuff” in user-space?

I’m far from a kernel expert, but I still have the i915 module loaded into the kernel on this bad boy, which I think most people would call a driver.

Backslash,

The heavy stuff would be things like shader compilation and state management for multiple different graphics APIs (OpenGL and Vulkan mostly).

AFAIK Linux graphics drivers are usually separated into a userspace and a kernel space component, like amdgpu on the kernel side and RADV/RadeonSI within Mesa on the userspace side. So you do not need to do a full reboot to e.g. benefit from performance optimizations within Mesa to get things like faster shader compilation or more efficient draw call submission, which I think most people care about when doing driver updates. In fact you don’t even need to soft reboot, because once Mesa is updated, all following uses of it already run the new version, all without a reboot. However if your GPU is not yet supported by the kernel side, then Mesa is of no use to you.

That being said, yes the kernel side is a very important part of the driver, but it’s such a low-level driver that very few people would be able to do much of anything with it, which is why I made that distinction.

Zamundaaa,

You could always do that. If you update Mesa, any applications you start after updating will use the new version of Mesa

Chais,
@Chais@sh.itjust.works avatar

Oh? I thought I’d at least have to reload a kernel module or something.

Toribor,
@Toribor@corndog.social avatar

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.

throwawayish,

Hard-reboots are no longer required on Silverblue when installing or upgrading packages (besides kernel) through rpm-ostree. Arguably one should only sparingly rely on rpm-ostree for installing packages. But it’s great to have access to soft-reboot when setting up a new system.

spez,

So is this like that windows ‘fast boot’ or whatever it’s called thing?

bamboo,

It is nothing like that. Windows fast boot is just fancy resume from hibernation.

aksdb,

It’s a mix. It hibernates what would be the result of a systemd soft-reboot, before user space starts up again.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • uselessserver093
  • Food
  • [email protected]
  • aaaaaaacccccccce
  • test
  • CafeMeta
  • testmag
  • MUD
  • RhythmGameZone
  • RSS
  • dabs
  • oklahoma
  • Socialism
  • KbinCafe
  • TheResearchGuardian
  • Ask_kbincafe
  • SuperSentai
  • feritale
  • KamenRider
  • All magazines
    •