There's also `systemctl soft-reboot` which initiates a userspace-only reboot, which quickly restarts the system without going through the full hardware and kernel initialization process.
I'm glad to see this. Almost 18 years ago I implemented a similar kexec device+memory preservation for a storage vendor. It was done on a Linux kernel of that day, and it had had a memory reservation and handoff protocol between the two kernels to keep some specific PCI device alive, allowing for state restoration at the application side. I'm proud of the fact that the kernel replacement was just under 1 second in execution (after init process optimization) and the whole kernel+app was less than 10 seconds.
Was hoping this would be mentioned. This version of functionality will probably be more universally accessible to all configurations as compared to the soft reboot released in 254:
Soft rebooting was even more exciting for me, but I wasn't able to get it to work on my bluebuild based system (customized universal blue). I haven't tried it in a while though.
6.19 added a new Live Update Orchestrator, which allows significantly more of the system to be retained while doing a kexec / Kernel Handover like transisiton to a new kernel too. https://www.phoronix.com/news/Linux-6.19-Live-Update-LUO https://lwn.net/Articles/1033364/
Systemd added support in recent 2.61. Theres also now ways to have user stores, that survive across switches. https://www.phoronix.com/news/systemd-261
There's also `systemctl soft-reboot` which initiates a userspace-only reboot, which quickly restarts the system without going through the full hardware and kernel initialization process.
But that doesn't give you kernel updates, being userspace only?
Real men use: killall -9
I'm glad to see this. Almost 18 years ago I implemented a similar kexec device+memory preservation for a storage vendor. It was done on a Linux kernel of that day, and it had had a memory reservation and handoff protocol between the two kernels to keep some specific PCI device alive, allowing for state restoration at the application side. I'm proud of the fact that the kernel replacement was just under 1 second in execution (after init process optimization) and the whole kernel+app was less than 10 seconds.
Was hoping this would be mentioned. This version of functionality will probably be more universally accessible to all configurations as compared to the soft reboot released in 254:
https://github.com/systemd/systemd/releases/tag/v254
Soft rebooting was even more exciting for me, but I wasn't able to get it to work on my bluebuild based system (customized universal blue). I haven't tried it in a while though.