Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A guide to Linux signals

linuxvoice.com

Post reply on HN
Print view View original

21–30 of 37 posts

Re: A guide to Linux signals

#21

Post by ratboy666 »

rewqfdsa wrote: post #16
ratboy666 wrote: post #9

Earlier quoted context omitted.

Linux (Unix) signals are per-process. What is hard about making signals cooperate? Are you referring to a signal generated while in a signal handler? raise() is supported on Windows, but kill() isn't (directly, signals don't seem to be well supported as an IPC mechanism on Windows -- although there appear to be kill() style mechanisms).

> What is hard about making signals cooperate? 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 an…

sigaction() returns the old action. This permits chaining of the actions. Specifically for SIGSEGV, if Library B does not want the signal, it can invoke Library A (without caring what it is). Similarily, A can invoke B. "Unloading" cannot be done, unless you are aware of the load order. This is a general issue -- dlclose() is reference counted, and you wouldn't know if it actually unloaded the library.

Re: A guide to Linux signals

#23

Post by noselasd »

mixblast wrote: post #22

What about SIGSTOP and SIGCONT? They're quite useful to pause and resume processes (Ctrl-Z).

And indeed also very useful for testing. "what happens if we simulate this process being a bit slow" - send it a SIGSTOP. Doing so can simulate a number of other weird cases too as observed from the outside , such as a process trashing on swap, NFS hanging.

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)

Re: A guide to Linux signals

#25

Post by useerup »

ratboy666 wrote: post #21
rewqfdsa wrote: post #16

Earlier quoted context omitted.

> What is hard about making signals cooperate? 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 an…

sigaction() returns the old action. This permits chaining of the actions. Specifically for SIGSEGV, if Library B does not want the signal, it can invoke Library A (without caring what it is). Similarily, A can invoke B. "Unloading" cannot be done, unless you are aware of the load order. This is a general issue -- dlclose() is reference counted, and you wouldn't know if it actually unloaded the library.

> Unloading" cannot be done, unless you are aware of the load order. This is a general issue -- dlclose() is reference counted, and you wouldn't know if it actually unloaded the library.

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.

Re: A guide to Linux signals

#26

Post by teddyh »

mixblast wrote: post #22

What about SIGSTOP and SIGCONT? They're quite useful to pause and resume processes (Ctrl-Z).

As I usually have to point out, Ctrl-Z sends SIGTSTP, which can be caught by a signal handler – unlike SIGSTOP, which is not sent by any key in the terminal driver, and which can not be caught by a signal handler.

Re: A guide to Linux signals

#27

Post by silon7 »

fulafel wrote: post #20
rewqfdsa wrote: post #16

Earlier quoted context omitted.

> What is hard about making signals cooperate? 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 an…

It's actually alarmingly common for Windows C/C++ apps to paper over crashes with SEH try { } catch (segfault) { /* seems to work */ } this way. Even Microsoft's own apps used to do it, maybe they still do. You run into this when running random apps under a debugger.

There's nothing structured about core dumps. Better to do nothing so the developer can see a clean core dump.

Re: A guide to Linux signals

#28

Post by SEJeff »

Symbiote wrote: post #24

ps -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.

Re: A guide to Linux signals

#30

Post by JoeAltmaier »

throw7 wrote: post #29

One thing that might have been nice to note is the rules regarding what you can and can't do in signal handler code.

One of my pet peeves: documentation that doesn't say anything. Methods (and callbacks) are listed by name with some thrifty description of argument. But none of the important stuff is ever there: is it reentrant? stateless? Who owns each non-scalar argument? Can it be invoked from user space? installable driver? kernel driver? Signal handler? Does it have latency constraints? Can I use it from a different thread than it was constructed under? Is it protected during thread death? Is it atomic vs what other methods? What other apis are allowed/forbidden when writing a callback?

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.

Post reply on HN