Earlier quoted context omitted.
Can someone write a program to tell me how much money I’d need to give you?
Give me time and I'll tell you at the end how much money you need to give me.
Agreed, take all the time you need.
Show HN: A “living” Linux process with no memory
111–117 of 117 posts
Re: Show HN: A “living” Linux process with no memory
#112Earlier quoted context omitted.
A more pragmatic book is The Linux Programming Interface, by Michael Kerrisk. It is Linux-specific though, but that's probably fine. Uninterruptible process sleep is covered in section 22.3. Threads, in chapters 29–33. Signals, chapters 20–22. The proc file system in section 12.1. Memory mappings, chapters 49–50.
The version I have covers kernel 2.6. Is that new enough to still be useful?
Useful yes, complete no.
Uninterruptible sleep, signals, memory mappings etc have not changed fundamentally.
Namespaces and cgroups are new concepts in Linux, they won't be covered. IIRC user namespaces appeared in 3.14. New cgroup hierarchy got somehow usable much later than that.
The new concepts are needed for containers. Not at all relevant for the original article here.
Re: Show HN: A “living” Linux process with no memory
#113As someone who doesn't understand much of what's going on here, what resources would you suggest I study to improve?
A more pragmatic book is The Linux Programming Interface, by Michael Kerrisk. It is Linux-specific though, but that's probably fine. Uninterruptible process sleep is covered in section 22.3. Threads, in chapters 29–33. Signals, chapters 20–22. The proc file system in section 12.1. Memory mappings, chapters 49–50.
I haven't read that book, but I enjoyed a conference tutorial about cgroups and namespaces by Michael Kerrisk. One of the best trainers/presenters I have experienced!
Re: Show HN: A “living” Linux process with no memory
#114Earlier quoted context omitted.
A more pragmatic book is The Linux Programming Interface, by Michael Kerrisk. It is Linux-specific though, but that's probably fine. Uninterruptible process sleep is covered in section 22.3. Threads, in chapters 29–33. Signals, chapters 20–22. The proc file system in section 12.1. Memory mappings, chapters 49–50.
The version I have covers kernel 2.6. Is that new enough to still be useful?
Of course. Linux famously "doesn't break userspace" so almost anything that works in 2.6 still works today.
Re: Show HN: A “living” Linux process with no memory
#115Earlier quoted context omitted.
The version I have covers kernel 2.6. Is that new enough to still be useful?
Useful yes, complete no. Uninterruptible sleep, signals, memory mappings etc have not changed fundamentally. Namespaces and cgroups are new concepts in Linux, they won't be covered. IIRC user namespaces appeared in 3.14. New cgroup hierarchy got somehow usable much later than that. The new concepts are needed for containers. Not at all relevant for the original article here.
Actually he is still maintaining a list of changes since the book has come out. http://man7.org/tlpi/api_changes/index.html
Re: Show HN: A “living” Linux process with no memory
#116I'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…
what happens to the other threads? Are they killed?
Can a malicious process use this to avoid being killed
Re: Show HN: A “living” Linux process with no memory
#117I'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…
what happens to the other threads? Are they killed? Can a malicious process use this to avoid being killed
All the other threads are killed.
A malicious process can't do useful work - as soon as the kernel gets unstuck, the signal will get delivered to the thread and kill it.