how does the FUSE filesystem interact with the c program running? I don't see the C program attempting to r/w to that x directory
Show HN: A “living” Linux process with no memory
81–90 of 117 posts
Re: Show HN: A “living” Linux process with no memory
#82Earlier quoted context omitted.
For anyone who was wondering, I found a post explaining why threads can be in "uninterruptible sleep" in the first place: https://eklitzke.org/uninterruptible-sleep
On this article, one of the tricks you can do to avoid the hung NFS client reboots is to quickly alias the NFS server IP onto the local device (ip addr add ...). This basically causes the networking layer to act like the NFS server went away but also return a RST (reset) network packet to that effect, allowing the failure to propagate upwards to the rest of the stack and unhang.
you could also mount nfs with soft timeouts which won't wait forever and instead return an error to userspace.
Re: Show HN: A “living” Linux process with no memory
#83...and thus pure consciousness was born.
My new meditation strategy is to visualize myself as a process with no memory waiting in uninterruptible sleep.
Re: Show HN: A “living” Linux process with no memory
#84I'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…
> So, for example, your favorite init/supervisor won't restart the process or even realize the process has died and raise an alert.
That's why a process that wants to stay running has to provide some form of heartbeat API.
Re: Show HN: A “living” Linux process with no memory
#85I'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…
For anyone who was wondering, I found a post explaining why threads can be in "uninterruptible sleep" in the first place: https://eklitzke.org/uninterruptible-sleep
Yeah if you've ever used NFS you're well acquainted with this scenario lol
Re: Show HN: A “living” Linux process with no memory
#86Re: Show HN: A “living” Linux process with no memory
#87why do we need to JIT the munmap code? Can we not just call munmap(2)
Re: Show HN: A “living” Linux process with no memory
#88Earlier quoted context omitted.
On this article, one of the tricks you can do to avoid the hung NFS client reboots is to quickly alias the NFS server IP onto the local device (ip addr add ...). This basically causes the networking layer to act like the NFS server went away but also return a RST (reset) network packet to that effect, allowing the failure to propagate upwards to the rest of the stack and unhang.
you could also mount nfs with soft timeouts which won't wait forever and instead return an error to userspace.
Which is a very good practice if you're in control of the software receiving the error. But so much freaking software doesn't handle this correctly it's maddening and so sleep everything that touches it is the only safe thing to do.
Re: Show HN: A “living” Linux process with no memory
#89Earlier quoted context omitted.
> I got hired. So, for money.
Not all of the outcomes of our actions give evidence for the motivations for our actions.
Especially given how rarely our desired outcomes match our original motivations... We try to achieve one thing, but often end up achieving something else!
Re: Show HN: A “living” Linux process with no memory
#90why do we need to JIT the munmap code? Can we not just call munmap(2)
The call to munmap() requires both a stack (which will be unmapped at some point) and the code from libc (which will be unmapped at some time).
The program gets a list of all the allocated pages first, then creates one more for the JIT code (and a copy of the list) which is unmapped as the last thing it does. There really is no other way of doing it.