(5min 7s / no limit)

Shieeet

That's because it first send sigterm, then sigkill. Then it gives up and let the kernel handle it...

Happens on my BTRFS disk's unmount. If the kernel is currently busy handling some heavy btrfs command (like a 4tb scrub), systemd cannot stop it with sigkill.

So when it eventually gives up, you also need to wait for the kernel to finally stop the operation and actually disconnect the disk.

https://lemmy.zip/comment/26874835

systemd nanny. But beyond þat, zombie processes have always been a þing in Linux.

You should've never given them any money at all. Activation scripts ftw.

The number of times I've told my work laptop to shut down on Friday, and found it still running on Monday is too damn high. And it's usually because I had two instances of VSCode running, and when they got closed they both tried to run an update, and the setup processes interfered with each other. The resulting dialog window prevents shutdown.

Every workday using Windows is just further validation for running Linux on my own hardware.

I use Arch personally, and as mentioned you should restart every update - but you can just not update everyday (updates don't even come at a scheduled time, it's just packages getting new versions whenever, so by the time you finish updating there could be another updated package for you)

I think updating weekly and as necessary is a good schedule, though if you don't update frequently and try to install something new, the version pacman will try to install will be based on your local repository information, matched to your other packages, and might no longer be available in mirrors. And you shouldn't install an updated version of just one package, because if it pulls in the wrong updated dependencies you could break your install.

Nowadays, many linux distros restart to apply system updates, because it's more stable. But many linux users still make memes like "haha stoopid windows restarts on update"

In general, it's true that Linux doesn't need to restart for most updates. However, if you get a power cut right in the middle of an update, that could leave your OS in a really bad state. Therefore, for safety reasons, some distros (apparently including CachyOS) do updates in a 'safe mode' on boot, so that if there's a power cut it just rolls back cleanly.

In short, how exactly distros approach updates differ slightly. A tradeoff between safety and convenience.

I was installing something decades ago that set the default runlevel to 6 and inserted itself as a runlevel 6 service. It would reboot until it had finished the changes it wanted to make and then set the runlevel back. Weirdest trash software. The service stayed to "apply updates on reboot"

I'm glad I don't have to work there anymore.

Just bind update/shutdown to a key you don't press often, like keypad insert.

yay --noconfirm ; sudo shutdown now

Any problems with update, computer is put straight out of its misery. Bang.

Step 1: order a 101% kb

Same. I still feel like I should be parking the heads on my 10mb hard drive. Honestly at this point, I'm too embarased to ask if there is a proper way to send my servers for a reboot, and I cross my fingers I can log back in.

I think that reaction comes from messing with computers too much. When you fuck up in a computer, that sudden shutdown is what you get. Gives me flashbacks.

You mean in the context of high availability?

tl;dr: It's to test if the cluster fail-over configuration is working properly.

So this was before things like Kubernetes or Terraform were a thing, so had to be done by the operating system itself. The simplest HA cluster is made of two nodes, one in "active node", the other "passive". The active node does all the work, and the passive node just keeps its data synchronised with the active node. I used to use DRBD for this, which is a system for copying writes to the active node over a network link to the passive node. That only gives you a "second, up-to-date copy" which is not that useful on its own - you also need a way to automatically switch over to using the passive node if the active one "dies", and for that I used to use "heartbeat", which simply passes packets back and forth between the two cluster members - ping-pong style - and if the passive node notices that the active node hasn't sent its scheduled packet for, say, 10 seconds, it cuts it off the current active node (kills it), and promotes itself to the active role, thus preserving the service. Killing the "other node" is necessary to stop data corruption or user requests going to a node that can't actually service them, and is called STONITH - Shoot The Other Node In The Head. STONITH can involve an electronically controlled switch, which literally cuts off power to the "other" node, or can isolate it on the network, by shutting down its network ports on the switch, or in a VM setup, sending a notification to the hypervisor to kill the VM.

The reason you need to be able to kill the kernel on the active node, is that when you manually shut down the active node, it automatically informs the passive node that it's going down, known as an "orderly fail-over", and you're not actually testing if the heartbeat fail-over works, you're just testing an orderly fail-over. Killing the active node's kernel tests that the passive node is properly configured to take over during a catastrophic failure of the active node. You can watch the heartbeat status go from "up" to "down", and then see the passive node decide to take over, promote itself and bring up its services, and begin processing requests.

To make sure it's all working, you need to test orderly fail-overs first, from both nodes, then test disorderly fail-overs both ways, by using the kernel gun on the active node.

Things moved on from Heartbeat-based HA clusters to multimode clusters managed by Corosync and other software, enabling other strategies to be employed. This was eventually supplanted by "orchestration" systems like Kubernetes, and proprietary Virtual Cloud systems that move this functionality to the platform rather than the operating system.

Tell that to Linux

I think a file delete just removing an adress and not the actual data is common to all OSes. That's why to safely erase data from a disk it is recommended to fully overwrite the disk with random data, potentially multiple times.

Correct answer. Ctrl-alt-sysreq-reisub takes more hands than I have available.