Aren't these Unix (or, more accurately, POSIX) signals, rather than Linux signals?
A guide to Linux signals
31–37 of 37 posts
Re: A guide to Linux signals
#32One thing that might have been nice to note is the rules regarding what you can and can't do in signal handler code.
The short answer is: not much. Basically change a global variable declared as volatile sig_atomic_t.
You can find more information in this presentation [1] (from 2004!).
Re: A guide to Linux signals
#33A note: SIGHUP is far from obsolete in its original purpose. We may have stopped using modems but people still log in to Unix machines in ways that can get disconnected. If you SSH in to a machine and your SSH session is cut off by a network issue, your shell (and any command you have running) will get a SIGHUP.
There's more than that in SIGHUP. It's sent to the process group owning the terminal[1] (/dev/tty[1-X], /dev/pts/*) when said terminal is closed. Your shell, Midnight Commander, Vim, Emacs, and what not terminates when you close your terminal emulator window. [1] I don't quite remember what happens to other process groups, since you could have some background jobs stopped.
[deleted]
Re: A guide to Linux signals
#34Re: A guide to Linux signals
#35ps -ef | grep foobar is more easily done with pgrep foobar or perhaps pgrep -a foobar
or ps -ef | grep fo[o]bar So 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.
That's nice. Apparently, we can place the brackets around any of the characters too! Can you explain how it works?
Re: A guide to Linux signals
#36Earlier quoted context omitted.
or ps -ef | grep fo[o]bar So 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.
That's nice. Apparently, we can place the brackets around any of the characters too! Can you explain how it works?
Sure, the square brackets in posix regex (used by grep) are for character ranges. You can wrap any single character in the brackets and it works the same.
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.
Re: A guide to Linux signals
#37Earlier quoted context omitted.
or ps -ef | grep fo[o]bar So 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.
pgrep already excludes itself
Sure but that isn't often nearly as useful as something like:
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}'