A guide to Linux signals(linuxvoice.com) |
A guide to Linux signals(linuxvoice.com) |
[1] I don't quite remember what happens to other process groups, since you could have some background jobs stopped.
Seriously? You find a system with global events where you must perform your own resource book-keeping to clean up the correct resources nicer than structured exception handling?
Strongly disagree. It's hard to make different signals cooperate. Vectored exception handlers in Windows have built-in support for arbitrating between different users.
As an embedded programmer, I end up reading library source most of the time trying to find these answers. And if it isn't open, then I have to black-box test or lard calls up with semaphores which might not be necessary. The state of API documentation is in the stone age.
You can find more information in this presentation [1] (from 2004!).
[1] http://man7.org/linux/man-pages/man7/signal.7.html [2] Advanced Programming in the Unix Environment, Second Edition
ps -ef | grep foobar
pgrep foobar
pgrep -a foobarSo you don't have to | grep -v grep :)
I ask people to explain what that does and how it works as a sysadmin interview question.
I've found that doing that to etcd causes other etcd in the cluster to randomly hang - while it handles a lot of other failures fine (instant poweroff, network partitioning, randomly crash etcd, sending SIGSTOP to on member of a cluster breaks everything - I don't know if that's improved since I did those tests though)
ps -efH | grep foob[a]r
Where you can see the arguments and whatnot. Both are good to know.
You can use awk's ability to do posix regex and emulate pgrep with:
ps -efH | awk '/foob[a]r/{print $1}'
So foob[a]r matches the literal string foobar. If you grepped foob[ab]r it would match both literal strings foobar and foobbr. However, it doesn't match the literal string foob[a]r because [] is a character range. To match that, you'd need to escape it something like foob\[a\]r, which would not match the literal string foobar. This is why you don't need grep -v grep
Understanding how and why this works will dramatically help you slice and dice text strings in a shell, so it makes a great SysAdmin interview question.
Library A wants to handle SIGSEGV for memory mapping X. Library B wants to handle SIGSEGV for memory mapping Y. Which of them calls sigaction? What if both do? What if then unload one of the libraries?
Windows handles this interaction sanely. Sigaction does not.
> raise() is supported on Windows, but kill()
Windows splits the jobs of signals into structured exceptions and APCs. You can definitely send an APC to another thread: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
Yup. Which is exactly why Windows is more sane: No chaining, "unloading" (i.e. unsubscribing) can be done robustly. In the absence of a mechanism like SEH on Linux, signals are (mis)used. Signals are a crude, unstructured way of handling internal termination.