I've taken to calling such a process a "lich," because it's not quite a zombie - the parent can reap a zombie by calling wait(), but the lich has used magic to avoid true death.
Show HN: A “living” Linux process with no memory
11–20 of 117 posts
Re: Show HN: A “living” Linux process with no memory
#12Can this be implemented in Go?
Re: Show HN: A “living” Linux process with no memory
#13Can this be implemented in Go?
EDIT: Aaaand there is the crew!
Re: Show HN: A “living” Linux process with no memory
#14> Why? I don't know. I thought it was funny This is the profit. While job searching I went on an interview where I got asked why I did a side gig listed on my resumee. "For friend or for money?" It was neither and I said "I don't know, because programming is fun?" I got hired.
Why are you learning how to create linux processes with no memory? Why are you hacking overloading into Python? Why are you writing programs for fun? To dig unnecessarily deep and force your way into programming's secrets.
Re: Show HN: A “living” Linux process with no memory
#15Not sure why people care what it's written in. I'm pretty sure people wouldn't complain if this was a blog post written in english rather than a program written in C and python2.
Re: Show HN: A “living” Linux process with no memory
#16Can't think of any way to profit from this. Just reboot your box.
Re: Show HN: A “living” Linux process with no memory
#17I've now seen a similar case multiple times in the wild - if a process has a thread in uninterruptible sleep (e.g., blocked on a bad disk or a stuck network filesystem) and you kill it, the process dies, but the kernel waits forever for that thread before informing the parent process. The parent doesn't get SIGCHLD, and wait() doesn't return. (So, for example, your favorite init/supervisor won't restart the process o…
Re: Show HN: A “living” Linux process with no memory
#18Earlier quoted context omitted.
I'd be much more reluctant to get on OP’s case about it than GP, but there’s a strong argument to be made that this hurts the overall python ecosystem.
There's also a strong argument to be made that people shouldn't have to care about ecosystems that are so delicate that a proof of concept in a previous version "hurts the overall [ecosystem]." "How dare you use a hammer! We're all using Hammer 2 now! I don't care that it was 'Only one nail," put it down and pick up Hammer 2! Your hammer is what, ten years old? That's ancient! It's not even compatible with my Hammer…