3 ms·

Are there any differences between threads and processes in how signals are handled? I recently learned that aside from processes there are process groups, proc

by rendaw 2y ago

Are there any differences between threads and processes in how signals are handled? I recently learned that aside from processes there are process groups, process sessions (setsid), process group and session leaders, trees have associated VT ownership data, systemd sessions (which seem to be inherited by the entire subtree and can't be purged), and possibly other layered metadata spaces that I haven't heard of yet. And I feel like there's got to be some way to tag or associate custom metadata with processes, but I haven't found it yet. I really wish there were an overview of all these things and how they interact with eachother somewhere.

oguz-ismail 2y ago
> I really wish there were an overview of all these things and how they interact with eachother somewhere. man 7 signal
- fc417fc802 2y ago
  Also see `man 2 clone` and `man 7 cgroups`.
eqvinox 2y ago
> Are there any differences between threads and processes in how signals are handled? Yes, absolutely, there are thread-directed and process-directed signals; for the latter a thread is chosen at random (more or less) to handle the signal.
skissane 2y ago
> Are there any differences between threads and processes in how signals are handled? Yes. As signal(7) notes [0], Linux has both “process-directed signals” (which can be handled by any thread in a process), and “thread-directed signals” (which are targeted at a specific thread and only handled by that thread). For user-generated signals, the classification depends on which syscall you use (kill/rt_sigqueueinfo generate process-directed signals, tgkill/rt_tsigqueueinfo generate thread-directed). For system-generated signals, it is up to the kernel code generating the signal to decide. So the same signal number can be thread-directed in some cases and process-directed in others > systemd sessions (which seem to be inherited by the entire subtree and can't be purged) At a kernel level those are implemented with cgroups. > I really wish there were an overview of all these things Unfortunately I think Linux has grown a complex mess of different features in this area, all of which are full of complicated limitations and gotchas. Despite attempts to introduce orthogonality (e.g. with several different types of namespaces), the end result is still a long way from any ideal of orthogonality [0] https://man7.org/linux/man-pages/man7/signal.7.html https://man7.org/linux/man-pages/man7/signal.7.html
- rendaw 2y ago
  Oh thanks! I was recently having `runuser -l` silently not do the session setup because of the systemd thing, so maybe there's a better way (than laundering it through a process launcher daemon in a separate tree) to handle that. I forgot capabilities with another 5 layers (+) of different flags and applied differently to processes and files... (and then namespaces, etc)

by rendaw 2y ago

oguz-ismail 2y ago

> I really wish there were an overview of all these things and how they interact with eachother somewhere. man 7 signal

fc417fc802 2y ago
Also see `man 2 clone` and `man 7 cgroups`.

eqvinox 2y ago

> Are there any differences between threads and processes in how signals are handled? Yes, absolutely, there are thread-directed and process-directed signals; for the latter a thread is chosen at random (more or less) to handle the signal.

skissane 2y ago

> Are there any differences between threads and processes in how signals are handled? Yes. As signal(7) notes [0], Linux has both “process-directed signals” (which can be handled by any thread in a process), and “thread-directed signals” (which are targeted at a specific thread and only handled by that thread). For user-generated signals, the classification depends on which syscall you use (kill/rt_sigqueueinfo generate process-directed signals, tgkill/rt_tsigqueueinfo generate thread-directed). For system-generated signals, it is up to the kernel code generating the signal to decide. So the same signal number can be thread-directed in some cases and process-directed in others > systemd sessions (which seem to be inherited by the entire subtree and can't be purged) At a kernel level those are implemented with cgroups. > I really wish there were an overview of all these things Unfortunately I think Linux has grown a complex mess of different features in this area, all of which are full of complicated limitations and gotchas. Despite attempts to introduce orthogonality (e.g. with several different types of namespaces), the end result is still a long way from any ideal of orthogonality [0] https://man7.org/linux/man-pages/man7/signal.7.html https://man7.org/linux/man-pages/man7/signal.7.html

rendaw 2y ago
Oh thanks! I was recently having `runuser -l` silently not do the session setup because of the systemd thing, so maybe there's a better way (than laundering it through a process launcher daemon in a separate tree) to handle that. I forgot capabilities with another 5 layers (+) of different flags and applied differently to processes and files... (and then namespaces, etc)