reupload because i mixed up sigterm and sigkill like a dumb fuck
I find my system usually has to wait 90 seconds to kill KDE plasma when I use it without a login manager and then try to shut down…
Everybody gangsta until “A stop job is running for …”
Systemdead can be a dick.
Keeping it real hell yeah
user error doesn’t count
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.
Zfs stuck on suspended pool. Make pool with 1 disk, disconnect disk, pool suspended, io blocking until force shutdown, process uninterruptible (no kill -9).
I feel like it’s handled way better nowadays though.
TL:DR No, lmao. But timer was lowered at some point to 3min for most distros, afaik.
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 😉
A stop job is running for User Manager for UID 1000 (12s / 2 mins)
( 1min 59s / 2 mins )
…
( 2 mins / 3 mins )
???
(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.
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.
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?
Xkill is my favorite. I prefer aiming the gun and pulling the trigger myself
Set a keyboard shortcut for it. Ctrl + Alt + Esc is mine.
Reverse meme when it’s time to install the updates.
Windows in that case is “I MUST REBOOT IMMEDIATELY PREPARE TO LOSE ALL UNSAVED DATA IN 3. 2. 1…”
When I switched to win 10, I actually gave them more money to get the pro version for access to the group policy editor so I could control updates and never have to deal with my PC telling me it’s time to restart on its own. Because I was stupid.
When it came time to switch to Win 11, I did the much more sensible thing and installed Fedora instead. I started with cinnamon and even though I ended up disliking it also, it was still way better than the windows experience.
You should’ve never given them any money at all. Activation scripts ftw.
Not quite. I will RESUME FROM THIS FUCKING “MODERN SLEEP” shit, even though you the user want to turn this shit right off, do it without any warning watsoever, close all your fucking windows and good luck if you have lost work or not.
“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.”
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 )
also yes i know
shutdowntypically usessigtermand waits nicely, but it doesn’t take 45 seconds for no damn reason like windowsalso
sigkillis funnierWindows: the shutdown mechanism cannot execute correctly because this process is still running:
ShutDownProcess
hoss
taskkillis pretty funny too
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.
systemd nanny. But beyond þat, zombie processes have always been a þing in Linux.
The first time I shutdown a Linux computer, I thought I broke something it happened so fast.
Been doing Linux for decades. sudo reboot is still very jarring.
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.
No
This but deleting a folder:
- Are you sure you want to delete this
- Delete too large to fit in garbage bin, so are you really sure
- Couldn’t delete stuff (for no clear reason)
- Even as admin file locks were hard blocking without any easy way to unblock
Meanwhile on Linux with sudo rm -rf, it’s just gone as demanded.
Partially true. The difference is that in Linux, when you delete a file, you’re just removing the directory entry (potentially just one of many entries that point to the same data). The filesystem doesn’t actually remove the data and reclaim space until all open handles are closed and no remaining directory entries point to the data.
Any running processes that have the file open are able to continue to read and write that data via the handle despite the directory entry being removed, until the handle is closed.
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.
If you delete a still opened file on Linux then the file will disappear for all processes which didn’t already open it, all programs that did already open it can still read and write to it and the file on disk will never be overwritten (as in, used for other files) as long as there’s still a process with the file open.
Simplifying how it works: The file you see is a link to the actual file(inode), when a program opens a file using this link they get a copy of the link. As long as one link/copy of it still exist the file won’t be deleted. When a program closes all its links get cleaned up so on shutdown all files which only have processes referring to them get marked as deleted.
that’s a different thing. if you delete a file that is still opened by a process, the space will not get freed up until that process also closed the file. until that point the filesystem still keeps track of the file, it is just not present in any directories anymore.
I mean you could probably delete files with powershell then idk.
“YOU CAN’T SHUT DOWN YET, STEAM STILL RUNNING” -Win10, literally every time.
The fuck?
I’ve had it yell at me because it couldn’t close some dialog window that explorer opened because I was trying to shut it down
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.
Why not just leave your work laptop mining crypto for you while you’re away?
also true for boot (not from suspended state), in my experience.
windows: wait, let me display the windows logo for 10 seconds, then show a spinny circle, then show the lock screen, then when you try to enter your password, it loads your user profile for another 5 minutes before it shows your desktop icons
linux: click the power button -> 1.5 seconds later i see the lock screen. enter password and it’s just there.
Back when i still had windows as a second boot option, it was soooo annoyingly slow to boot (like 3 minutes or so). I thought it’s because I installed it on a HDD, not SSD (and that was indeed part of the reason). One day when my internet broke though, I realized it was actually super fast to boot suddenly. It just spent half the time downloading stuff from the internet before, during boot. From then on I just pulled the ethernet cable before booting windows. Fucking joke of an operating system
I’ve found it to be very dependent on the distro and the hardware it’s running on. Back when I was playing around with distros I definitely tried some that felt like you snapped your fingers and had a desktop. But I settled on Fedora and that takes longer to boot for me than Windows. Not that I mind, 30 seconds once a week or so just isn’t important to me.
Are you perhaps on Wifi? I noticed that Fedora is has configured Systemd to wait for online network before continuing starting the login services.
No, this is on a wired machine. I have another one on wireless also running Fedora and I’d say that one is slower to boot, however it’s also on a Ryzen 3600 where my main PC is a 5700X so that’s kinda expected anyway.
I don’t know what comment section or post are talking about. Default timer for systemd on arch is 3 minutes (and I think it’s default for most distros). Whenever some service fails to quit on reboot, system will stuck for 3 minutes until systemd decide to kill it. I need to manually configure it lower to like, 10 seconds, cause there shit ton of services that always fails to quit.
And not like I’m using old pentium - my system build on AM5 with amd 7700x, 128gb of 5600MT\s ram and 7900xtx, with kingston nvme pcie4 ssd’s on top of that. It’s literally “best case scenario”.
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!
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.
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 -eor something like that. You can also usesystemd-analyze blameto 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.confUncomment (remove #) this line and set it either in minutes or seconds:
DefaultTimeoutStopSec=10sI really don’t understand why default is so high. Even on old and weak hardware shut down shouldn’t take too much time.
Thank you so much! Hopefully this works.
Don’t be a pussy and sigkill process number 1.
Had the pleasure of installing some HPE proprietary crap on RHEL the other day.
After the cli installer ran it printed: rebooting now.
It then killed PID 1 to force the reboot …
We were flabbergasted. Why would the first and only method of asking the system to reboot be to shoot the system in the head?
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.
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.
Too much typing. Real men just press Alt+SysRq+L.
Just bind update/shutdown to a key you don’t press often, like keypad insert.
yay --noconfirm ; sudo shutdown nowAny problems with update, computer is put straight out of its misery. Bang.
Also if cat walks on the keyboard, computer is put straight out of its misery. Bang.
Step 1: order a 101% kb
Just hold on to your butt and cut the main power.
But then don’t forget to switch back to main power before the auxiliary power runs out of fuel or things will get really bad.
Unless it’s the movie and they cut out the whole auxiliary power and just set it up such that all power goes out and no one thought of being at the power station to get the main generator back up and running asap before cutting the park’s power.
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’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.
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.
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 may be weird but I always like opening a terminal and I have sdn aliased to shutdown now
If you use Emby Desktop, when it’s full screen it interrupts all shutdown commands. Only GUI option is ‘cancel’, running shutdown remotely fails… Just need to exit full screen but who the hell decided an Electron app was more important than my choices
