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)
nah, you can have micro-kernel features on linux, but you can’t have monolithc kernel features on microkernel, there’s zero arguments in favor of a micro kernel, except being a novel project
ORLY.
Do explain how you can have micro kernel features on Linux. Explain, please, how I can kill the filesystem module and restart it when it bugs out, and how I can prevent hard kernel crashes when a bug in a kernel module causes a lock-up. I’m really interested in hearing how I can upgrade a kernel module with a patch without forcing a reboot; that’d really help on Arch, where minor, patch-level kernel updates force reboots multiple times a week (without locking me into an -lts kernel that isn’t getting security patches).
I’d love to hear how monolithic kernels have solved these.
I’ve been hoping that we can sneak more and more things into userspace on Linux. Then, one day, Linus will wake up and discover he’s accidentally made a microkernel.
I thought the point of lts kernels is they still get patches despite being old.
Other than that though you’re right on the money. I think they don’t know what the characteristics of a microkernel are. I think they mean that a microkernel can’t have all the features of a monolithic kernel, what they fail to realise is that might actually be a good thing.
I thought the point of lts kernels is they still get patches despite being old.
Well, yeah, you’re right. My shameful admission is that I’m not using LTS because I wanted to play with bcachefs and it’s not in LTS. Maybe there’s a package for LTS now that’d let me at it, but, still. It’s a bad excuse, but there you go.
I think a lot of people also don’t realize that most of the performance issues have been worked around, and if RedoxOS is paying attention to advances in the microkernel field and is not trying to solve every problem in isolation, they could end up with close to monolithic kernel performance. Certainly close to Windows performance, and that seems good enough for Industry.
I don’t think microkernels will ever compete in the HPC field, but I highly doubt anyone complaining about the performance penalty of microkernel architecture would actual notice a difference.
Windows is a hybrid kernel, and has some interesting layers of abstraction, all of which make it slower. It’s also full of junkware these days. So beating it shouldn’t be that hard.
Yeah to be fair in HPC it’s probably easier to just setup a watchdog and reboot that node in case of issues. No need for the extra resilience.
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.
But generally microkernels are not solution to problems most people claim they would solve, especially in post-meltdown era.
Can you elaborate? I am not an OS design expert, and I thought microkernels had some advantages.
Can you elaborate? I am not an OS design expert, and I thought microkernels had some advantages.
Many people think that microcernels are only way to run one program on multiple machines without modyfing them. Counterexample to such statement is Plan 9, which had such capability with monolithic kernel.
That’s not something I ever associated with microkernels to be honest. That’s just clustering.
I was more interested in having minimal kernels with a bunch of processes handling low level stuff like file systems that could be restarted if they died. The other cool thing was virtualized kernels.
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.
HURD 2, the return of rust
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.
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, if you’re using systemd
SIGTERM it was since original init
Almost every time I restart my Windows PC from an update, it sits on the “closing apps screen” or “restarting” screen then gives up completely and I have to force it to shut down/restart
And, just about every other time I restart with an update, it closes apps and then just fully shuts down after the update!
It’s super graceful! 😭
“restarting” for 15 minutes. Then crashes. Now I have to reinstall updates and go through it all over again. I hate how crappy the windows update process has become.
Except for the immutable versions I have, Linux almost never needs to reboot after an update. Upgrades, yes, but not standard updates. And even after upgrades, it just works [(except for one of the immutable versions I have)].
I usually close all programs before shutting down / rebooting, anyway (a habit I picked up from Win95 days, where it would crash if programs prevented it from shutting down), so I don’t really feel this SIGKILL issues.
Linux almost never needs to reboot after an update
Doesn’t it often need a reboot to apply some updates?
I rember reading something along those lines then I was researching why Fedora installs some updates after a reboot. Most
Fedora is the immutable I was referring to that does need to reboot. Linux Mint and OpenSuse only need to reboot after an upgrade. I’ve never had to reboot them after updates. Mileage may vary, of course, as different people have different software, tools, and libraries installed.
I was talking about regular fedora. It’s not that you have to reboot, but you don’t get to use those updates until you do. The most obvious example is updating the kernel and its modules.
You’re correct. A kernel update would fall under the umbrella of a system upgrade, where the system needs to shut down to allow underlying components to be reloaded.
Linux actually also has a graceful shutdown process. It tells apps its shutting down by sending SIGTERM, and its up to each process to flush data asap, do whatever they gotta do, and then shut down.
If they don’t listen then linux will indeed pull out the
baseball batchainsawkatana and make processes die whether they want to or not.Windows’ might be complex, but it is NOT graceful. If you have notepad open with unsaved text, then shutdown will never shut down - but nothing on the screen will make this obvious to a non-technical person.
