Systemd Introduces Userspace Reboots??? 

The idea? Cool as heck. Would I use it? Probably! Honestly, the verbose `systemctl userspace-reboot` is perfectly fine, it's clear, it's unambiguous, and it's not like you're going to be doing it dozens of times per day without making a script or alias around it.

Honestly I've never really gotten the hate for systemd. Like, okay, sure, it combines a lot of functionality into one software suite, but like, it works well enough. And also, there are other programs that people love that go way, way beyond just "do one thing and do it well" - emacs, anyone?

Why not just put a flag for the reboot command like this "systemctl reboot --userspace"?

I can see this being really useful for servers. It's probably less useful for the average desktop user. Most of the time a normal reboot doesn't take that much time. I can see this being very useful on anything that requires very high uptimes. Especially if you can find it with live kernel patching.

I use Tumbleweed, so I get a lot of new kernel versions, but there are plenty of updates that come without a kernel update, so I would still find this to be handy. It would be easier than manually restarting services or doing a full reboot. Big thumbs up for this one.

This is properly sick! Once the patch lands on my system, I'll be able to restart my home server without hearing it take off like a jet plane.

FreeBSD already does this via "reboot -r" ( as root) if I remember correctly. It comes in handy when when not updating the kernel and a hardware reboot takes a long time.

As a Linux server admin, this seems like an incredibly useful feature in situations where total system uptime is critical. From my experience, userspace software gets updated far more frequently than the kernel, so the ability to "refresh" your userspace without restarting the entire kernel makes a lot of sense. The ability for userspace software and services to then resume from where they left off without any special sauce patches is monumental. Combine this with either kernel livepatching or kexec, and you can effectively have 100% hardware uptime (not accounting for actual hardware failure).

The bikeshedding is just eye roll worthy

This would be extremely useful on bare-metal servers where you need to reboot to switch to a newer root, like with Openshift/OKD and RHCOS/Fedora CoreOS, as bare-metal servers have a very long boot initialization process. Looking forward to this be available to be used there.

*This comment is being written while I'm watching the video* tbh, that's neat. It would be great for smth like fedora silverblue and other ostree based distros.

I'm really happy the outro is changed. Good job!

This is perfect for containers/k8s. In fact seems perfectly suited for it. As kernel updates are handled independently on the host nodes, this can be a HUGE improvement there. The typical nginx + code system can run forever, only restarting on nginx version changes. Code changes can just be remounted while nginx is up with this. Some other kind of services can also use this ... (tomcat apps... anything that allows dynamic reloading)

This sounds awesome! Perfect for an update that does not involve a kernel update. Been thinking about this since systemd was adopted in Arch. I think a lot of the systemd hate come when they reinvent the wheel to replace perfectly good existing solutions. This seems like a perfect solution that doesn't currently have an existing solution AFAIK. As for the command name, I could care less, as long as it isn't something that sounds like an advertisement that we deal with all to often. ie: something like systemctl systemd-userspaced-rebootd-RHELd-Gnomed-wontfixd

it would be great if there was an option to also unload all kernel modules when userspace-shutting down, so that they would be reinitialized as well during userpace-reboot.

This is a great feature for servers, enterprise servers have complicated boots that involves hardware checks and memory verifications that take too much time, doing userspace reboot would minimize downtimes drastically!

6:53 This is one area where most *nix shells are deficient. I had a look at the “complete” system that was added to bash, but only because it was preventing me typing file names that I knew to be perfectly valid for those commands. So I just turned it all off. I remember some older systems that had more of the sort of thing we need. Back in the 1980s I used BTOS/CTOS for a while, and when you pressed RETURN on a command, you got a form to fill in that showed all the relevant options for that command. And then later Apple’s MPW development environment included “Commando”, that would pop up a nice GUI dialog in a similar fashion. Where do we get something like that now?

Wow, you just dredged something up from my brain. I used to use the SysVinit trick to go to runlevel 1 then back to runlevel 5 all the time, back in my old Debian days (before systemd).

Fun fact: did you know that, by default, "shut down" in Windows *does not* shut down? It enters some sort of hibernation of whatever, but doesn't shut down properly. "restart", on the other hand, performs a full OS cycle.

Solaris has had this feature for ... probably over a decade? Except there it addresses your security/updating concern too. Rather than keeping the kernel, they spin up a new kernel from the old kernel too - in essence, the old kernel acts like a bootloader. They call it a "fast reboot", because initial bootstrap on big iron (think: a server where the firmware is performing memory training on a few terabytes of DRAM) can take tens of minutes. And it's really smoothly intergrated with ZFS snapshots. You perform a system update into a new clone of your rootfs, this gets tagged as a new "boot environment, then you simply "reboot -fe " and the system quickly loads the new kernel & all userland from the new BE. Up and running in a few seconds, all fresh, and rollback in case of issues is trivial (just boot back into the old BE).

So, a soft-er reboot. That's a pretty genius option for multi-user environments. Not a feature I need right now, but if I ever end up having to share a server, this'd be great for cleaning up semi-orphaned processes, or forgotten Screen processes.

10:45 What you see being described here, is already not the original telinit anymore, but they explain how it translates to systemd commands. This is because telinit has been mapped to systemd on some distros, for backwards compatibility. Seems that they didn't do this on Arch Linux anymore. However, you can still type _systemctl rescue_ or _systemctl isolate rescue.target_ to enter the rescue mode. I tested this again. But my conclusion is that resue mode still keeps a lot of system services running. It does not look like a full userspace reboot.

OpenRC is very much sys5's successor, and it can shut everything above boot runlevel down and restart them. You can also shut everything above boot down, and then `switchroot` before restarting them. Keeping open file handles sounds like a good way to have hard to track down bugs if you are switching root.

I sysadmin a lot of servers and sometimes a reboot is the quickest way to sort out issues. Having this userspace-reboot function would be amazing because most of the time I'm not rebooting to update the kernel.

I think this kind of existed on jailbroken iphones for a while. it was referred to restarting your "springboard." It usually just got reset instead of the whole phone when your tweaks malfunctioned

I have for years wondered why this never was a thing. It seems like such an obious thing to want to have, but it is probobly non-trivial. I can't wait!

Nice, this would be crazy handy!

I remember doing this sort of thing by hand and look forward to the feature.

This sounds great. Perfect for reducing downtime after updates with Silverblue/ublue style distros.

love the outro music!

Definitely useful feature especially if you are grinding & just want to continue working.

For servers with infrequently updated kernels, there's definitely a use case for this. For my desktop that doesn't get regularly shut down, I just don't want to see this become the default in GUIs. It's a lot cleaner and easier to explain if reboot really does flush everything out. And that's to say nothing of retraining the linux users who don't actually want to learn the details (yes, they exist). Add an extra button to the "log out/shutdown/reboot" dialog, sure, but don't make "reboot" mean "reboot userspace" by default.

Big benefit of this could be reducing the dependency on Lights Out Management for zero-touch systems. So for example rather than needing to use some base management you can have the system it's self-manage this. I wonder how it would work with LUKs encrypted volumes.

Great feature, some dedicated servers take like 5 minutes just to post.

5 months later and i'm pretty sure this is implemented as "soft-reboot" now. in my case, it's useful on stuff like an old machine running hdds cause a full reboot takes forever and this takes some five seconds, not counting logging back in.

Nixos already does this, but in a more targeted way - it starts added services, stops removed services, and restarts affected services. Still very cool for the rest of Linux users, though!

Since this is a super fast reboot, you'll use it the most. At this point typing out "userspace-reboot" would waste so much time. `renew` is far more convenient. And it's not like people learn how to use systemd from the command names... there is the documentation for that.

The "going down to rescue level" trick in SysVInit can still be performed on a systemd OS - run `systemctl emergency` or (`systemctl rescue` - it's similar but i prefer "emergency" as it has less stuff running and mounted), then from that target you can run `systemctl default` to return to the full OS. I'm pretty sure you can change the root filesystem somewhere in the middle, if you wanted, but i didn't try that. Obviously, a single command to do the loop, and also being able to hand open network sockets across the jump, will be an invaluable feature that no other OS has (not even MacOS, though keeping sockets open is a server thing and no one sane is running macos servers...)

urb - userspace reboot. Easy! :D It's an interesting feature, I've been trying to improve outages of my servers. Thanks for the info!

That's super cool for a server reboot that doesn't need a kernal reload.

I'm properly one of the nerds, who actually reguarly used kexec on my Linux desktop. Because i could. And then let it properly reboot, when i shut it off when i was finished. I will definetely find this usefull.

I've been waiting for something like this for a while now. My system seems to have done this type of reboot once as untended behavior and got a super fast reboot have been wondering how to replicate it since.

'Let's not wait for firmware,boot loader, kernel, initrd, to reinitialize on a reboot' 'super fast switching from one OS version to the next' great that systemd has this as well now but for years you could do the exact same thing on openRC/sysvinit with reboot -k It uses kexec -l to load a kernel, reboot and run kexec -e after the init system is down.

I'm curious about what level of a speed-up this means. A fresh boot takes ~30s on my PC. How long would a "renew" take? Is it still like 20s or more like 5s? I know exact numbers vary and very system-dependand, but orders of magnitude are still interesting to know.

This is exactly what I need. Kexec doesn't work with my new GPU anymore (6800XT). Worked with my old RX590. Real reboots just take too long. This looks like the perfect solution for a very fast "reboot" when you don't have to necessarily restart your kernel.

This will be a godsend for anyone with running a system on an encrypted partition, especially if they’re testing annoying hardware quirks like screen backlights or Nvidia Settings behavior. BTRFS is a maybe; it’s actually very convenient to modify a GRUB entry for a one-time boot to start up in a different subvolume, and a userspace reboot will not return the user to GRUB. Instead, a user would need to edit /etc/fstab, and those changes are not temporary without the user going back and reverting the changes.

Unfortunately not helping for kernel upgrades which is the main reason I reboot anyway

Win9x also had a 'userspace reboot' in a way. It would just reload Windows within DOS, it was common with driver installs. I believe the "Restart computer" option still did a complete boot process, however. You could also just exit to DOS mode and type "win" to boot back into Windows without shutting down the DOS kernel. This became irrelevant after XP though, since WinNT always required a full restart.

Realy nice feature! I run my own little server with docker on it. Honestly it would be nice if i could reduce the complete reboot to once a new kernel is released. Currently i restart them about every 2 weeks because of librarys. No big deal but a would be nice if the server is running again in 2sec flat.

This doesn't use kexec? I mean it's not something obscure or server only, that's what I expect systemd to soft-reboot right? Run the regular reboot procedures and start the same / maybe even new kernel

This seems useful for those rare cases that I'd like to play something on Steam but, the Controller is not being read properly or the audio is not set up correctly.

How is this different from dropping to runlevel 1 and back? Aside from the resource passing. Can't you still do that with "systemctl isolate rescue[dot]target" and "systemctl isolate multi-user[dot]target" or "systemctl isolate graphical[dot]target"? (replace [dot] with .) Should be able to define a new target that just bounces in a single go, I'd have thought.

Sounds like ram block offsets which are supposed to be randomized then wouldn't be, leaving systems vulnerable to every buffer overflow all over again. I don't see at all how to keep the kernel running during a reboot while still randomizing ram addressing for security as we do normally these days.

I don't understand why so much of the information is focused on "image based systems" which, if I understand it right, is equivalent to immutable I don't use an immutable distro (outside of my steamdeck, which I actively wish was just regular Arch and not immutable) and I can absolutely see a usecase where refreshing(Sus-ing) would be useful but people keep talking about it like it's a feature that would be useless outside of image based distros(I can only think of 3, steamos, silverblue, vanillaos(?))

kexec doesn't really take long to boot a new kernel, maybe 5s? It already works with systemd too to cleanly shutdown before switching to the new kernel.

There are people who don't like this? Why??? It's just a fun and cool feature that's useful for us immutable fans. If anything, I'm more worried that people who could've used it, never used it because they never discovered it. Just call it userspace-reboot, it's fine, we have autocompletes anyways. It's going to be very useful when you need to do a few abroot or rpm-ostree while setting up your system.

Cool feature! But why do some people freak out whenever Lennart Pottering does anything? As with most people, I know him from systemd. And I've gotta say that I've still got a bit of a love/hate relationship with systemd-a good bit of that is documentation. It's always had pretty strong low-level documentation: Manpages. If you understand systemd at a deep level, that's all you need. But IMO there are four levels of documentation, and systemd was kind of pushed out as "the new standard" before the other three types really ever got written. As that's changed, I've gone from hating it outright to liking it about half the time and being irritated the other half. What do I mean by "levels" of documentation? Let's compare to bash. Most people know: Run programs in the path, ls, cd, cp, mv, rm. That is surface level documentation. You're not really "using" bash if that's what you know, but it's enough to get some basic tasks accomplished. Then there's the fluent user stuff, you probably know how to write common scripts, run more complex loops and conditionals at the bash prompt, set up your bashrc, etc. Then there's person who really understands the userspace side of it. They might knot know how it all works, but they know the advanced features. In bash's case they'd be the ones who can write programs in bash, not just scripts. And then you get the deep lore level. With documentation at all those levels (level 3 is a little weak still), a person who isn't universally opposed to systemd can find ways to make it do what they want at the level they need, and so there's room to like what it does well, because you can actually use it to do those things. The issue is that Lennart Pottering is an arrogant egotist who firmly believes his own hype train. He's not alone in that, but honestly nobody's that impressive in reality and it makes people not want to give him an inch even when yeah the thing he created is pretty decent. Not perfect. Not God's gift to humanity. Not the only right way it could ever be done. But decent, and better than what we had before by a wide margin.

Does the kernel have regular security updates? I think I only remember specter/meltdown, tcp-syn-cookies(yeah, I'm old), and I'm struggling to remember more.

Cool feature for servers, however I don't see myself using in on my personal PC. With nvme SSDs and fast CPUs, the downtime difference is just not worth it.

Worth leaving Devuan for!

How about “sudo shutdown -ruserspace now”

systemd-rebootd

pottering's horns are always regrowing after he breaks them ... wonder how long it will go on til he learns

I saw your systemctl userspace-reboot alias venting

Why is preserving file descriptors useful? It's not like any process could use them, right?

Man, macOS has this “feature” on reloading userspace from the days when launchd has emerged

i hope this will make gpu passthrough less of a hassle, usually i have to reboot my system to a uki with an different initrd in order to avoid nvidia drivers from loading earlier than vfio ones to be able to pass it to a windows vm

As one of the use cases is image based systems, how would this compare for --apply-live command for rpm-ostree from the users perspective?

What's the point of preserving fd-s if your userspace will be killed and those files will belong to nobody? I don't get it. Also my concern about Poettering software is that it trying to control EVERYTHING on your system and doesn't tell what exactly it's doing. This is bad if you want do something yourself or there is a bug that not present in another software (or you know how to bypass it) but something is already defaulted to keep doing it's thing and also control everything else so you can't just kill it.

Pair this with an LTS kernel and you're good to go!

Should be systemctl reboot --userspace or systemctl reboot -u, since systemctl reboot already exists.

imagine rebooting your Homeserver remotely without typing in your Luks 2 key, cause it's held in kernel space

I don't even like systemd very much, but this is an awesome feature. Good job, systemd guys! 👍

I will never understand why people prefer having commands be super cryptic instead of just spelling stuff out. Sure, it maybe made sense in the early 80s, but tab completion, scripts and aliases have existed since forever at this point

It doesn't matter to me, since I don't have a problem doing traditional reboots, but it sounds like an interesting feature even tho I hate systemd in general. What I don't get is why anyone has a problem with calling it "renew" instead of something else. There's shutdown for a full power cycle, restart or reboot for a softer reboot, why not "renew" for a partial reboot?

Love the new outro

With literally no experience getting that close to how the kernel functions, could it not be possible (perhaps in the near future) to launch the new kernel in a kind of virtualized state, shut down userspace, pass control to the new kernel and shut down the old one, then reload userspace in order to perform a live kernel update? Perhaps there is a hardware reason that one kernel cannot pass control onto another kernel? This seems to me to be a highly desirable feature. In my mind, where I have no idea of the world in which the kernel lives, I can picture a second kernel loaded into ram, updated to match the state of the old kernel, then perhaps a pointer address change hands the reigns over to the new kernel. I know it can't be that simple or it would have been done.

Sounds nice, but I feel it won't be of much use to me. I shutdown my computer whenever I go to sleep myself, or go to work for the day etc. My reasons for this: the electric bill and the wear of my computer.

I only ever reboot when I need a new kernel, which isn't that uncommon on a rolling release. I think userspace-reboot is good but it would be better to have an alias like ureboot. I am the type of people that explore new features typing up stuff, I would probably be curious about "ureboot" then look up what it is than looking up userspace reboot and finding out how to do it.

i love systemd

I would love for systems where reboot after update is enabled (like Fedora) to deduce if there was a kernel update or userspace-only and automatically select one or the other

I'm waiting for the moment Pottering approves the new name as "sus", if not, I'm making an alias.

So this is like login out your user... but without actually login out? I wonder how this look on practice. I will try it out.

If this was on MS, the tiitle could be Power Nap mode to be introduced? Sounds like a good feature, but i'm one of those who gets scared any time I see a kernel update.

This is a gamechanger for immutable systems like Silverblue and MicroOS

Let’s see… if a full power cycle is a “hard reboot”, and an operating system reboot is a “soft reboot”, then a userspace reboot could be called a “softer reboot”? “Reshoe”? “Nap”? systemctl userspace-reboot works well though. It’s straightforward too!

1:33 Actually, this is what containers (e.g. LXC) already do.

A full system reboot only takes a few seconds on my system, so I probably wouldn't need this feature, but if there is a need for it somewhere then why not implement it.

I'd be for "systemctl reboot" as the normal reboot, and "systemctl softreboot" as this userspace option.

7:38 exactly what I use for suspend

I think windows had this in like windows 98. You'd initiate a restart and get just a "Windows is now restarting" message, skipping vga bios/system bios initialization.

If this is something the "Linux never needs to be rebooted" people will use, that's better than just not rebooting in any fashion and missing ALL the updates. Personally, this is kind of cool toy I guess? Would've been amazing years ago when boots and reboots took a long time, but now it's like a minute tops. Really not concerned about that. And also, pretty much every time I update, I get a new kernel version. Need to do a full reboot for that anyway, so not much use for this userspace-only reboot. But maybe that's just my Arch brain talking.

Why not just restart those updated service and programs instead of init restart ? Full reboot on only kernel update

is it diffrent from SysRq + e/i ?

im also not a systemd hater , and i use it on every of my linux installs. and im really fine with the software but i think the name is a bit odd /weird, i know it mimics launchd a bit , but named usually indicates a daemon , so systemdaemon ,awesome. makes sense , but daemon is just the daemonized version of a program so , there should be a, system program aswell that does the same thing but 'not daemonized', that together that the short form of system is sys, wich is obviously already in use , so by choosing that name , systemctl is probably the shortest form you can give it without becomming dubious. service / serviced would have worked aswell , and unitd since all its parts are called units anyway , even main/maind was still free to use :), ontopic , i do think that userspace reboots are a nice to have but i think its purpose might not be a good thing for linux in general (meaning it might boost the popularity and usabillity of readonly distro's above that of regular installs , and i wile nice i thing they are the opposite of what linux used to be , something you could poke around in anywhere and change things

thing is reboots now are mega fast now i use nvme storage but for hdd storage systems this does make sense

This sounds like container reboot, similar to rebooting LXC container in Proxmox...

_can you do that with sus reboot?_ Network manager: _WHat?_

Systemd complainers are usually people who say, we always did it like this, why change it?

Reboot!? You mean when the power line is off for a moment? Yeah, that happens, I should get an UPS. Joke aside, I want the opposite. Easy upgrading of the Kernel without a reboot.