(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.

I couldn’t find better screenshot, but I’ve definitely seen this happening due to zombie processes after just regular use, rather than just broken mount. I feel like it’s handled way better nowadays though.

user error? what user error? mount a network drive, disconnect the network, then try to unmount it. best part? most programs will stall for a long time when it tries to access the directory.

So too would be attempting to shut down Windows without saving and closing your applications then 😉

The point here is that SystemD's natural behavior is to send SIGTERM then wait an eternity.

Those "service XY is shutting down (5sec/2min)" messages you sometimes get on shutdown are coming from SystemD not waiting for 3 seconds like the meme suggests, but waiting for minutes before giving up and switching over to SIGKILL instead.

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.

"Oh, you need to give a presentation in 3 minutes? Too bad. I decided it's time to update now, and you WILL spend 45 minutes installing updates before the computer will boot."

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.

How do you configure this?

Idealistically - you supposed to figure out what wrong with particular service that causing long shutdowns, by using: journalctl -b -1 -e or something like that. You can also use systemd-analyze blame to do the opposite and figure out what causing long startup.

But if you a normal human being that doesn't have weeks to figure out bugs on kernel level with AMDGPU power management, then there a simpler solution - you just need to lower timer. In file:

/etc/systemd/system.conf

Uncomment (remove #) this line and set it either in minutes or seconds:

DefaultTimeoutStopSec=10s

I really don't understand why default is so high. Even on old and weak hardware shut down shouldn't take too much time.

CachyOS based on Arch, with basically arch repos, so it have rolling release with frequent kernel updates. And yes, you need to reboot your system to apply kernel update, so CachyOS (cause it targets casual audience) explicitly prompts to user that reboot is needed, to avoid weird arch quirks like losing ability to connect new usb devices after kernel update (arch is quirky like that). Better safe than sorry.

You can just, well, not update that frequent. My server also running arch, I update it like, each couple of months, updated packages will just pile up and go in one update, that the beauty of rolling release (the ugly side is that no one tests if big update like that will work or not, so you may end up with dead system or it just wont update for example, lmao).

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.

Why would the first and only method of asking the system to reboot be to shoot the system in the head?

Because the lazy-ass dev didn't want to program in contingencies for using alternate methods, so he just used the one method that's guaranteed to work.

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.

Are you perhaps on Wifi? I noticed that Fedora is has configured Systemd to wait for online network before continuing starting the login services.

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.

Tell that to Linux

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.

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

No it’s a legit process state.

It does. It also works over RDP connections where Windows "helpfully" hides the shutdown and reboot options in the start menu from the remote user.