this post was submitted on 07 Jul 2024
837 points (92.9% liked)
linuxmemes
20454 readers
565 users here now
I use Arch btw
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules
- Follow the site-wide rules and code of conduct
- Be civil
- Post Linux-related content
- No recent reposts
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Fake news.
Both Windows and Linux have their respective SIGTERM and SIGKILL equivalents. And both usually try SIGTERM before resorting to SIGKILL. That's what systemd's dreaded "a stop job is running" is. It waits a minute or so for the SIGTERM to be honoured before SIGKILLing the offending process.
Also fake because zombie processes.
I once spent several angry hours researching zombie processes in a quest to kill them by any means necessary. Ended up rebooting, which was a sort of baby-with-the bath-water solution.
Zombie processes still infuriate me. While I'm not a Rust developer, nor do I particularly care about the language, I'm eagerly watching Redox OS, as it looks like the micro kernel OS with the best chance to make to it useful desktop status. A good micro kernel would address so so many of the worst aspects of Linux.
Zombie processes are already dead. They aren't executing, the kernel is just keeping a reference to them so their parent process can check their return code (
waitpid).All processes becomes zombies briefly after they exit, just usually their parents wait on them correctly. If their parents exit without waiting on the child, then the child gets reparented to init, which will wait on it. If the parent stays alive, but doesn't wait on the child, then it will remain zombied until the parent exits and triggers the reparenting.
Its not really Linux's fault if processes don't clean up their children correctly, and I'm 99% sure you can zombie a child on redox given its a POSIX OS.
Edit: https://gist.github.com/cameroncros/8ae3def101efc08be2cd69846d9dcc81 - Rust program to generate orphans.
I haven’t tried this, but if you just need the parent to call waitpid on the child’s pid then you should be able to do that by attaching to the process via gdb, breaking, and then manually invoking waitpid and continuing.
I think that should do it. I'll try later today and report back.
Of course, this risks getting into an even worse state, because if the parent later tries to correctly wait for its child, the call will hang.
Edit: Will clean up the orphan/defunct process.
If the parent ever tried to wait, they would either get ECHILD if there are no children, or it would block until a child exited.
Will likely cause follow on issues - reaping someone elses children is generally frowned upon :D.
Zombie processes are hilarious. They are the unkillable package delivery person of the Linux system. They have some data that must be delivered before they can die. Before they are allowed to die.
Sometimes just listening to them is all they want. (Strace or redirect their output anywhere.)
Sometimes, the whole village has to burn. (Reboot)
Performance is the major flaw with microkernels that have prevented the half-dozen or more serious attempts at this to succeed.
Incurring context switching for low-level operations is just too slow.
An alternative might be a safe/provable language for kernel and drivers where the compiler can guarantee properties of kernel modules instead of requiring hardware guarantees, and it ends up in one address space/protection boundary. But then the compiler (and its output) becomes a trusted component.
Thank you. Came here to say this. Microkernels are great for limited scope devices like microcontrollers but really suffer in general computing.
Then you would need to move compiler to kernel. Well, there is one: BPF(and derivatives). It's turing-incomplete by design.
RedoxOS would likely never become feature complete enough to be a stable, useful and daily-drivable OS. It's currently a hobbyist OS that is mainly used as a testbed for OS programming in Rust.
If the RedoxOs devs could port the Cosmic DE, they'd become one of the best Toy OS and maybe become used on some serious projects . This could give them enough funds to become a viable OS used by megacorps on infrastructures where security is critical and it may lead it to develop into a truly daily drivable OS.
I believe the next step after that would be to wake up
Hey, we can always dream!
They have already ported apps from Cosmic though.
HURD 2, the return of rust
They are planning to port Cosmic DE, and have already ported several applications from Cosmic including the file manager and text editor if I remember correctly.
They've shown the COSMIC terminal working on their last showcase video
What does this have to do with Rust? Or redox, or micro kernels or Linux?
I don't think a microkernel will help with zombies.
Ok, how change of kernel would fix userspace program not reading return value? And if you just want to use microkernel, then use either HURD or whatever DragonflyBSD uses.
But generally microkernels are not solution to problems most people claim they would solve, especially in post-meltdown era.
This particular issue could be solved in most cases in a monolithic kernel. That it isn't, is by design. But it's a terrible design decision, because it can lead to situations where (for example) a zombie process locks a mount point and prevents unmounting because the kernel insists it's still in use by the zombie process. Which the kernel provides no mechanism for terminating.
It is provable via experiment in Linux by use of fuse filesystems. Create a program that is guaranteed to become a zombie. Run it within a filesystem mounted by an in-kernel module, like a remote nfs mount. You now have a permanently mounted NFS mount point. Now, use mount something using fuse, say a WebDAV remote point. Run the same zombie process there. Again, the mount point is unmountable. Now, kill the fuse process itself. The mount point will be unmounted and disappear.
This is exactly how microkernels work. Every module is killable, crashable, upgradable - all without forcing a reboot or affecting any processes not using the module. And in a well-designed microkernel, even processes using the module can in many cases continue functioning as if the restarted kernel module never changed.
Fuse is really close to the capabilities of microkernels, except it's only filesystems. In a microkernel, nearly everything is like fuse. A linux kernel compiled such that everything is a loadable module, and not hard linked into the kernel, is close to a microkernel, except without the benefits of actually being a microkernel.
Microkernels are better. Popularity does not prove superiority, except in the metric of popularity.
It was(see CLONE_DETATCHED here) and is(source)
Ok, this is not really good implementation. I'm not sure that standard requires zombie processes to keep mountpoints(unless its executable is located in that fs) untill return value is read. Unless there is call to get CWD of another process. Oh, wait. Can't ptrace issue syscall on behalf of zombie process or like that? Or use vfs of that process? If so, then it makes sense to keep mountpoint.
Except Linux does it too. If graphics module crashes, I still can SSH into system. And when I developed driver for RK3328 TRNG, it crashed a lot. Replaced it without reboot.
As I said, we live in post-meltdown world. Microkernels are MUCH slower.
I've heard this from several people, but you're the lucky number by which I'd heard it enough that I bothered to gather some references to refute this.
First, this is an argument that derived from first generation microkernels, and in particular, MINIX, which - as a teaching aid OS, never tried to play the benchmark game. It's been repeated, like dogma, through several iterations of microkernels which have, in the interim, largely erased most of those performance leads of monolithic kernels. One paper notes that, once the working code exceeds the L2 cache size, there is marginal advantage to the monolithic structure. A second paper running benchmarks on L^4^Linux vs Linux concluded that the microkernel penalty was only about 5%-10% slower for applications than the Linux monolithic kernel.
This is not MUCH slower, and - indeed - unless you're doing HPC applications, is close enough to be unnoticeable.
Edit: I was originally going to omit this, as it's propaganda from a vested interest, and includes no concrete numbers, but this blog entry from a product manager at QNX specifically mentions using microkernels in HPC problem spaces, which I thought was interesting, so I'm post-facto including it.
Clicking end task in windows task manager has definitely let the hanging task live in its non-responsive state for multiple hours before.
Been a while since I've been on Windows but I distinctly remember some button to kill a task without waiting. Maybe they removed it to make Windows soooo much more user friendly.
Off the top of my head: right click the task and hit end process. That has literally never failed me. Back in windows XP it might sometimes not actually kill the process but then there was always the "kill process tree" button to fall back on.
Yep, typically "Kill Process Tree" was like the nuke from orbit. You'll likely destroy any unsaved data, but it works nice when steam has 12 processes running at once.
It's not really a nuke as some processes might be protected. The nuke is to use debugger privileges. Far Manager can kill processes using debugger privileges, that will literally nuke anything and in an instant: the app won't even receive any signals or anything.
The normal Windows task manager's 'end task' button just politely asks the app to close - but then later will tell the user if the app is unresponsive, and offer to brutally murder it instead.
There is also the sysinternals Process Monitor, which is basically 'expert' version of the task manager. Procmon does allow you to just kill a task outright.
The end task doesn't terminate the app, it only sends a message to the window to close itself. The app will then decide what to do on its own. For example, if the app has multiple windows open, it might close the active one, but still continue running with other windows open. Or it might ignore the message completely.
The worst part of that is that you can't quickly login to check what it is (so maybe you can prevent it in the future?), or kill it anyway because it's likely to be something stupid and unimportant. And if it actually was important, well... it's gonna be shot in the head in a minute anyway, and there's nothing you can do to prevent it, so what's the point of delaying?
In the best case the offending process actually does shut down cleanly before the time is up. Like, some databases like redis keep written data in memory for fast access before actually writing the data to disc. If you were to kill such a process before all the data is written you'd lose it.
So, admins of servers like these might even opt to increase the timeout, depending on their configuration and disc speed.
I know what it theoretically is for, I still think it's a bad implementation.
Finally, I think that well written applications should be resilient to being terminated unexpectedly. If, like in your Redis example, you put data in memory without it being backed by persistent storage, you should expect to lose it. After all, power outages and crashes do happen as well.
Stop jobs are a systemdism and they're nice. I think the desktop environment kills its children on its own during reboot and it might not be as nice. Graphical browsers often complain about being killed after a reboot in GNOME.
AFAIK running firefox in a terminal and pressing
^C(SIGINT) has kind of the same effect as logging out or poweroff in GNOME (SIGTERM, if you're using systemd). This gives the browser (or other processes with crash recovery) enough time to save all its data and exit gracefully for the crash recovery the next time they are run.Please correct me if I'm wrong
SIGTERM it was since original init
Windows gives you the option to kill on shutdown if the app is trying to delay the process. I think it's ideal.
BTW you can control systemd and how fast it chooses SIGKILL after sending SIGTERM. I don't know why people complain so much about it. It's really just there such that things on your computer end properly without any sort of data corruption or something bad going on after a reboot or the next time you turn on your computer.