reupload because i mixed up sigterm and sigkill like a dumb fuck
I had to update a Windows 11 work laptop after not touching it for nearly a year. I click ‘shut down’ from the start menu and nothing happens. What? Try it again. Nothing again.
I have to hold down the power button before the screen shows a “slide to shut down” screen now. How did Microslop fuck up the ‘shut down’ so badly.
the alt f4 shutdown window present since win95/nt4 tends to work better than the latest slop menu they made
I love how the design is so bad now we’re missing the days when shutting down the computer required the “Start” button.
Three whole seconds? Ain’t nobody got time for that shit
Definitely not a systemd based distro in the meme
Maybe something I don’t know, but I send kill commands through btop all the time on a systemd based machine.
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.
Can I somehow set this timer to thirty seconds instead of three minutes and up?
There is the option to explicitly set
DefaultTimeoutStartSecandDefaultTimeoutStopSecper systemd service.If you don’t specify it in a service file, the default values from
/etc/systemd/system.conf(both set to 90s) will be used, so you can change those values to 30s, too, to affect all services (that don’t have their limit set explicitly) globally.
systemd nanny. But beyond þat, zombie processes have always been a þing in Linux.
A stop job is running for User Manager for UID 1000 (12s / 2 mins)
( 1min 59s / 2 mins )
…
( 2 mins / 3 mins )
???
That’s because it first send
sigterm, thensigkill. 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.
(5min 7s / no limit)
Shieeet
In those cases there’s an easy solution.
Step 1: sigh
Step 2: press the power button 5 or 10 seconds while contemplating why you decided to do a quick restart instead of keeping the session and do something actually productive
I recommend starting with SysRq+E before that, there’s a chance it gets whatever the shutdown was waiting for. And if that fails… REISUB my beloved.
RSEIUB. Raising skinny elephants is utterly boring.
I might be missing something, but the order I know and have always seen recommended is REISUB. Terminating processes might write data to disk, so it seems to me like you should sync after, not before. Though this is also generally unimportant with modern filesystems and storage media.
You can change that, but there is a maximum time when it just kills the job.
I think you can set the default stop job timer lower?
Ah, a systemd user I see!
sysvinit and OpenRC are just so much better.
deleted by creator
How do you configure this? I have often encountered minute-long restarts most of which was fixed by adding a service to kill the wine server on shutdown, but still it sometimes happens.
deleted by creator
Thank you so much! Hopefully this works.
I guess the difference is that sigterm usually closes all the programs pretty quickly; but ITT I am learning that is not always the case!
<_<
shutdown -f -t 0 -sI prefer Windows giving programs time to shut down properly. You can always click on ‘shutdown anyways’ or whatever the button is called. Also what kind of programs do you run that take 45 seconds to shut down?
That’s actually the default on Linux as well. This meme just gets shared every other week, perpetuating the myth. OP seems to be aware of that.
It doesn’t “give time” it just waits indefinitely, and if the program doesn’t terminate your laptop will just sit there until the battery dies. This has to be one of the dumbest aspect of Windows, and god knows there are many
Does that guy have frontbutt?
Unlikely. That is usually meant to depict his massive bulge.
Yes and a broken knee
Waow based based based based based
Ironic. Because a bug on CachyOS KDE made the shut down button in the quick menu disappear. Nobody in their community could help me or explain why. Generally I would say support is rather spotty with CachyOS in general. Of course you can shut it down in many other ways but that was my preferred one. So I just lived with it and instead used ctrl+alt+delete for a while until the button magically returned one day.
I may be weird but I always like opening a terminal and I have sdn aliased to shutdown now
I’m kind of a linux noob, and i currently run catchyos and there are some things i don’t really understand. Last time i used linux is like 10 years ago, and i read and experienced that a really big plus on linux compared to windows is that you don’t need to restart when yoj install or update, but on catchy, you need to restart almost every update, which is almost every day it seems. Another thing that puzzles me is that every now and then, i restart for the update and wander off, and when i come back i don’t use the pc anymore and want to shut it down, but in the log in screen there is no shut down button, just a restart button.
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.
deleted by creator
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.
Gonna make Lemmy pissed off, but installed on my machine Nobara, Cachy and Mint at some point. All of them had comparable if not worse boot and shutdown times to Windows 10. xD ( And worse performance in games but that’s due to having old Nvidia GPU xD )
Uninterruptible sleep entered the chat
Xkill is my favorite. I prefer aiming the gun and pulling the trigger myself
It’s not a request, it’s a warning. The machine will be without power soon, and it’s up to the machine whether it wants to prepare for that or not
Nah man. “kill” doesn’t shut the system down quickly. This is the “instant death” way - the kernel reset gun - no shutdown scripts, no disk sync, just reset to BIOS boot sequence, instantly:
As root:
echo 1 > /proc/sys/kernel/sysrq echo b > /proc/sysrq-trigger
If you change out the “b” in the second command for “o” it will just halt the kernel instead of rebooting. Still switched on, but the system is doing absolutely nothing.
I used to use this trick all the time to test high availability server clusters.
Pardon my ignorance, how does halting the kernel help? We’re you seeing if other instances jump in for the halted one?
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.
I see! That’s fascinating stuff. I only do simple home hosting, so I never get into deployments like this, or how things used to be done, but love to hear the intricacies of it.
Yeah it was wild, but I suspect few orgs do things that way any more.
