Wait how does a user space daemon exhausting its stack lead to a kernel panic?
This is likely because Unix semantics treat the init process specially: any process whose parent dies is re-parented to the init process. It's not clear what should happen to these processes if the init process itself went away, so the kernel just gives up.
[1] https://elixir.bootlin.com/linux/latest/source/kernel/exit.c...
In a server I generally want a crash immediately. But on a desktop I'd rather it limp along and give me a chance to finish writing my Hackernews post.
It depends really what your server does, and what the consequences of it doing the wrong thing are.
Keeping it small and simple to minimize bugs is perfectly viable and reasonable.
Fire an alert, remove that server from the load balancer, and fix the problem without your customers even noticing.
Or make sure if you're running a hobby-project architected platform that your customer expectations and SLAs are clear up front, and let it go down until Monday morning when you'll get around to fixing it.
I'd much rather _not_ have my desktop "limp along" in a poorly understood and probably exploitable fashion while the malware gets a chance to finish encrypting all my files...
If that costs the world the "benefit" of my shared wisdom in a half written Hackernews post, I'm good with that.
I call these the "already lost" situations. You've already lost, we're just arguing about how to distribute the lossage. While those discussions aren't completely pointless, it is important to keep it clear in our head we're arguing about how to pick up the bodies at a crash site and not how to prevent the crash in the first place; it's a different mindset.
Despite some moderately-justified mockery in the other messages in this thread, the answer really is "just don't crash and have secure code here", which is to say, "don't lose". It's exceeding hard to write and it's a very high bar, but at the same time, it's very difficult to imagine how to secure a single system when you can't even stipulate a core of trusted software exists. If you don't even have a foundation, you're not going to build a secure structure. In this case, by "secure" I don't just mean security, but also, functionality and everything else.
Systemd of course goes in the opposite direction: It assimilates as much functionality as possible from the OS into systemd (though to be fair, not all into PID1).
"Ummm, lets not do that, it's not such a great idea..." -- Windows Vista team, 2006
https://docs.microsoft.com/en-us/previous-versions//cc750820...
(Well, it came out late '96, so I suppose a bunch of that was actually done in '95.)
A proper init system similar to runit or s6 would be written in something safer (minimum unsafe) like Rust, be modular, simpler, follow UNIX philosophy, and not try to do everything in one process. Microkernel-style.