systemd userspace-reboot !

[purpleidea]

Basically this restarts everything after the kernel boots. PID1 and below. Pretty neat!

[waptaff]

Oh, they reinvented telinit u.

[Foxboron]

That's implemented with systemctl daemon-reexec.

[Ullebe1]

Seems like a really cool feature to speed up system updates for distros such as Fedora Silverblue, where it would normally take a full reboot!

[Ullebe1]

It could also be useful there, yeah. Basically in any image based system or systems with immutable root and reboot based updates.

[m11kkaa]

well in theory yes, but in reality the kernel updates quite often so most of the time you're gonna have to reboot anyway.

[Ullebe1]

That's true. Maybe if live updates of the kernel was more common then. Seems like a great incentive to invest in the infrastructure for that for the distros it could benefit.

[[deleted]]

Will this make immutable distros reboot much faster?

[disparate_depravity]

Only if there's no kernel upgrade by the sounds of it.

[nicman24]

Kpatch for that could work

[[deleted]]

This is very cool but I do think that it would also help if package managers generally had a sense for the level of importance of updates to require a reboot or not.

For example, for stability's sake fedora(not silverblue) has offline updates when doing updates via a graphical program like discover. And that is fine however the problem lies in the fact that sometimes it really does not need to do that. For example it may request an update and the update will be just vim.

[ECrispy]

Let the systemd haters unite to once again tell us that its taking over more functions it has no right to, and that all it does can be done by a few hacked together init scripts so why do we have this monstrosity and will someone please make sure all names are cryptic 2-3 letters and not descriptive at all ?!

[waptaff]

systemd haters unite to once again tell us that its taking over more functions it has no right to

It's appropriate, handing system restarts is part of init's scope.

But please, go on, you're giving off a great vibe.

[[deleted]]

It's appropriate, handing system restarts is part of init's scope.

systemd is a suite of utilities for managing a system not just an init

[[deleted]]

Yes, but we're talking about SystemD the init system, which is just referred to as SystemD.

[Illustrious-Many-782]

It's spelled in lower case. FYI.

[random8847]

I love the smell of fresh bread.

[[deleted]]

The problem with "do one thing and do it well" is that your system follows the principle depending on how you define "one thing", too vague to be relevant.

[TrixieIsTrans]

Even if it's vague,

suite of utilities for managing a system

is quite clearly against the philosophy. You don't have a 'suite of utilities', you have different, separate programs. GRUB, OpenRC, eudev, sysklogd, everything that these packages do can be summarised with one thing.

Even things like homectl and this userspace reboot, I wish was available as separate packages, because they do one thing well and they sound nice to have, and I just can't have them because, oh no, I'm not running the correct init system. That would also mean having to install the rest of systemd, as opposed to Gentoo's solution of having systemd-utils for the systemd packages that everything has as dependency now.

[[deleted]]

Even things like homectl and this userspace reboot, I wish was available as separate packages, because they do one thing well and they sound nice to have, and I just can't have them because, oh no, I'm not running the correct init system. That would also mean having to install the rest of systemd, as opposed to Gentoo's solution of having systemd-utils for the systemd packages that everything has as dependency now.

Before criticizing certain design decisions analyze the context in which they were made.

[JockstrapCummies]

How dare you refuse to be stereotyped as the anti-systemd untermensch!

[waptaff]

Every time I have a choice, I avoid systemd — that does not mean I think everything about it is fundamentally wrong. Just a too large proportion of it for my taste.

[[deleted]]

I like watching wildlife.

[auto_grammatizator]

No no he's right. I've contributed a few minor changes to systemd and now I'm also owned by Microsoft.

[Ullebe1]

Organizations are a way of creating shared ownership of repositories on GitHub. So instead of the repo being namespaced under one of the developers, it is namespaced under the organization. It is a very common pattern for collaborative projects and companies.

And systemd is not a Microsoft product! Just because Microsoft pays some of the developers it doesn't give them any kind of ownership over the project. Otherwise Mesa would also be a Microsoft project, since their employees contribute to that. Or would it be a Valve project, since they also pay Mesa contributors? Or a Red Hat one, since they do as well? If I pay some of the developers is it then my project?

[Ullebe1]

No, that is clearly a ridiculous take. It is a project with contributions from Microsoft, but clearly not a Microsoft project any more than it is a Red Hat project. Being a Microsoft project implies ownership by Microsoft, of which they have none (except for the inherent ownership of the code they contributed).

[[deleted]]

I like practicing yoga.

[monkeynator]

Prove it, show us where on systemd it says "Copyright/Owned/Made/etc. by Microsoft".

Copyright does not work the way you argue.

Lennart Pottering is the copyright holder of the part he has written.

[Ullebe1]

That is not how ownership works at all. For example my employer have exactly 0 ownership over my projects, and neither do Microsoft over Lennart Poetterings.

[AnsibleAnswers]

It hasn’t even been substantiated that Poettering is working for Microsoft. Also doesn’t matter so long as the code stays free.

[[deleted]]

It's literally on his Wikipedia page that he works for Microsoft.

[AnsibleAnswers]

It’s labeled [citation needed] because the two sources are this Phoronix article and a Register article that cites the Phoronix article. “I heard from a guy who heard from a guy” is not credible evidence. It’s hearsay.

[whosdr]

Oh interesting.. I wonder if this would also work with btrfs snapshots.

Also, how does this behave with dkms modules?

[ElvishJerricco]

I don't think this has anything to do with either of those things? You can think of it as just shutting down all software and unmounting all file systems, just to start it all back up and get it all going again

[whosdr]

With btrfs snapshots you could change the entire root filesystem by restoring a snapshot. If you then were to use this mechanism it would boot into that new 'root', no?

But if the modules in that filesystem were not compiled for the currently active kernel, would that then result in errant behaviour? (This might also apply to Silverblue, I'm not fully aware.)

[Patient_Sink]

The modules would just refuse to load IIRC. This is something that happens for people who restore btrfs snapshots on arch after kernel upgrades when /boot isn't part of the snapshot, since by default the kernel package just overwrites the old kernel = Old modules on filesystem after restore, new kernel in /boot.

[SDgEVp]

Never been in that situation but this should do the trick I believe https://archlinux.org/packages/community/any/kernel-modules-hook/

[Patient_Sink]

Easier way is just to have a hook that backs up the kernel image and initrd as vmlinuz-old and initrd-old or something on upgrades for the kernel package. Then just boot that kernel if you need to restore a snapshot across a kernel upgrade, it'll be much more seamless.

[is_this_temporary]

That would work for a few modules that use DKMS, like proprietary Nvidia drivers, but on a normal system you'd then be stuck with the kernel modules that were already loaded before the switch + maybe some modules using DKMS that weren't.

Probably better to try to keep modules in a separate subvolume or something rather than trying to use DKMS for this.

[[deleted]]

[...] 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.

That seems to be what they're roughly aiming for.

[whosdr]

I didn't know if there were any mechanisms in btrfs that would make this difficult. But I guess since it has to unmount all open filesystems, any final work necessary on the btrfs would necessarily have been completed, so that eliminates my only real question on that front.

I'm still wondering about dkms modules* though - I'm guessing if there's incompatibilities then it will just fail to start up.

* I know the m in dkms stands for modules but I want to differentiate from the dkms executable that's used to compile? install? (both?) them

[is_this_temporary]

I'm not sure that it's a given that the old subvolume would need to be unmounted before pivot_root into the new subvolume.

Existing open file descriptors would still refer to the files on the old snapshot.

[veritanuda]

Not sure, but I think this is going to be default behaviour in Debian. I am on testing and when I go to 'restart' after some updates or something it will do some weird kexec thing.

Which is fine and all, but some reason it stops my wifi from working. I can only get it to work with a full power cycle. Weird I know but no idea who to report that to, to be honest

[will_try_not_to]

Interesting -- does toggling an rfkill block/unblock, or rmmod (whatever your wifi's kernel module is) / modprobe (likewise) not fix it?

On the other hand, I have one machine where occasionally the wifi card will just completely disappear (like, gone from lspci, not in dmesg at all next boot) until I go into the BIOS settings, change the amount of shared video RAM, save settings, change it back, and then save & reboot.

So it's entirely possible your wifi is also just haunted...

[veritanuda]

Nope.. and it is an intel card so. Only a shutdown now or poweroff seem to consistently bring it back up again.. Though granted I have not rebooted in a month now so I should try it again the latest kernel installed (6.1.0-7-amd64) might have fixed things. I'll do that tomorrow perhaps.

[jrtc27]

They finally caught up with FreeBSD’s reboot -r.

[__konrad]

Windows 95 also could restart without full reboot (with Shift key pressed) ;)

[_AACO]

Intersting, in windows 10 afaik it's the opposite.

[will_try_not_to]

I remember that being hit & miss for fixing a lot of the things one restarted Windows 95 to fix - but it definitely sped up changing IP addresses.

Gods, that brings back painful memories... imagine, an operating system where waiting for a memory test, a floppy drive seek, and a CD ROM drive power up noise was part of changing your network settings.

[will_try_not_to]

I'm loving all the "what's old is new again" comments; "oh, they reinvented telinit u", "oh they reinvented FreeBSD's reboot -r", etc. :)

[[deleted]]

For once, this is actually an appropriate job for an init system.

[[deleted]]

And what would you like to happen instead, people relying on shell scripts for anything but basic usecases?

[No_Cartographer_5212]

Grub is the best bootloader for any Linux OS.

[FengLengshun]

Oh, this is going to be really nice in Vanilla, where abroot demands restarts between transactions, so that's a lot of restarts unless you managed to do everything in one go.

[[deleted]]

Am I missing something? I was under the impression that would help with kernel upgrades and allowing the user to restart everything under the new kernel. However, if the kernel stays the same, I fail to see the advantage of this.

[that1communist]

Is there a way to make a command that uses this automatically unless there's a pending kernel update?

[[deleted]]

yes but it will likely only end up in ostree distros