Email or username:

Password:

Forgot your password?
Lennart Poettering

Here's a fun new feature we are working on in systemd: userspace-only reboot. In order to reduce grey-out times on image-based OS updates to next to nothing we are making a reboot happen where kernel stays as it is, but userspace shuts down as usual, then possibly transitions into a new rootfs, and starts up again with an initial transaction as it would on a classic system boot. During the transition selected services can pass along their fds and listening sockets, to pass "live" resources…

10 comments
Lennart Poettering

…from the old system to the new system. This means: super-fast switching from one OS version to the next, with all service code restarted cleanly and comprehensively, but with selected resources passed through untouched, so that they can continue to operate. And it wasn't even that hard to implement: github.com/systemd/systemd/pul

Or in other words: let's not wait for hardware, firmware, boot loader, kernel, initrd to reinitialize on a reboot, let's just focus on userspace alone.

Jason Francis

@pid_eins Wow, that's impressive, that really is a simple patch. But I still think it's silly how much boilerplate ya'll C folk have to write just to implement one dbus call :P

Julian Andres Klode πŸ³οΈβ€πŸŒˆ

@pid_eins So kind of like telinit 1 followed by telinit 5?

I gotta say I don't quite like it, certainly it shouldn't be offered to users easily or automatically if no new kernels available, that makes triage a lot harder.

Speaking practically because getting the kernel out of whacky driver states, or the EC out of its whackyness is the main reason I need to reboot on a ThinkPad :D

James Henstridge

@juliank @pid_eins The ability to preserve file descriptors is a pretty big difference.

Imagine running a web server and being able to restart all of user space without dropping an incoming connection. The listening port 80 socket would remain open with incoming connections queued until the web server is ready again.

bluca

@juliank @pid_eins the main use case here is unattended systems that have every tight requirements on service interruption tolerance, rather than laptops, as it pretty much has to be paired with kernel livepatching

varx/tech

@bluca @juliank @pid_eins It certainly seems cool, but also like a great way to introduce extremely arcane bugs into a long-running system. :-)

Lennart Poettering

@juliank well, there's a rootfs pivot between the telinit steps. And its a telinit that can pass through fds for .socket units and fdstore. And there's also a "telinit u" in between. And its more than "telinit 1" btw, because we also tear down early boot.

So its considerably different actually.

Julian Andres Klode πŸ³οΈβ€πŸŒˆ

@pid_eins yeah much nicer and made for it rather than how I abused sysvinit to reboot my user space :)

James Henstridge

@pid_eins How does this interact with the TPM work you've been doing? Presumably the new user space will need to deal with any TPM state changes the previous user space made.

Lennart Poettering

@jamesh it doesn't do anything special for tpms. so the mesurements we do at regular boots between initrd and full system up we are going to do again, each time you softreboot like this. But I guess it's not a total loss for use of TPMs for FDE because presumably you'll leave the disk encryption unlocked during such a softreboot.

Go Up