1

What happens if a process gets a signal after it was stopped by SIGSTOP?

I am trying to understand and get a good picture of how this is handled. Unfortunately, all I could find was a short description of the signal but no details of particular use-cases.

As of now, my understanding is that while SIGSTOP is in effect:

  • SIGKILL will kill the process immediately
  • other signals will be gathered up, and on a SIGCONT, the signals on hold will be unleashed on the process, as if all of them were sent at that moment
  • while handling the bunched-up signals after a SIGCONT, sa_mask, sa_flags's SA_RESTART, etc. will be applied, as per normal

E.g., If there is a SIGSTOP -> SIGHUP -> SIGCONT sequence, the handling of SIGHUP will be put on hold until after SIGCONT is received.

I am not sure if that is correct.

I am still in the dark about these cases:

  1. I am still confused about the order of the bunched-up signals.

    E.g.: SIGSTOP -> SIGHUP -> SIGTERM -> SIGCONT: will SIGHUP and SIGTERM be handled in the order they are received, or in an arbitrary order?

  2. What happens if the same signal is received multiple times while SIGSTOP is in effect?

    SIGSTOP -> SIGHUP -> SIGHUP -> SIGCONT

  3. Will SIGSTOP interrupt a running signal handler? If signals were waiting to be handled, are they preserved until after a SIGCONT?

I have found some answers in the answers to these similar questions, but I am still unclear on the above things.

Zoltan K.
  • 473
  • 3
  • 12
  • Asking more than one question in one post makes it difficult to answer. Better write separate questions. What's specifically unclear about [Why does SIGINT not terminate a stopped process?](https://unix.stackexchange.com/questions/620919/why-does-sigint-not-terminate-a-stopped-process)? Signals are not queued. For example when you receive a `SIGCHLD`, there is *at least* one child process that has changed its state. Your code should be prepared to handle more than one related event when a signal is received. – Bodo May 02 '22 at 17:17
  • This is 1 question: what happens with the signals while a process is under the effect of SIGSTOP? But I found it would be a bit unclear, so I added some pointers about edge-cases which are muddy. I would expect someone writing a common rule, or guideline. I have provided an example for it, as well "From what I gather..." – Zoltan K. May 02 '22 at 22:12
  • "For example when you receive a SIGCHLD..." It is unclear to me, how is this related to my question? If you can tell me, which part of my question led You to write this, I do think I should edit that part. – Zoltan K. May 02 '22 at 22:14
  • 1
    The example of `SIGCHLD` is part of my reply to your question "What if there were multiple signals of the same type?" as an example for "Signals are not queued." I chose this signal because the meaning of `SIGCHLD` and the expected reaction of the program are more or less fixed. The meaning of other signals might depend on your specific program, so without seeing your source code I can not give a better example. – Bodo May 03 '22 at 12:32
  • Oh, I understand now. I don't have a specific code for it, I would like to understand how it works better, so that in the future I can determin if I should be worried about it in a given situation. Unfortunately, I did not find anything in detail about it, at most like a 2-sentence description. I would like to go beyond checking how it works "on my system", and either see some authoritative source which goes more into details, or listen to someone more experienced in this matter, covering the above use-cases, or give enough guide-line for me to work it out myself. – Zoltan K. May 03 '22 at 13:53
  • Related - [Why can't I kill a SIGSTOP'd process with a SIGTERM, and where is the pending signal stored?](https://unix.stackexchange.com/q/298644/100397) – roaima May 18 '22 at 08:12

1 Answers1

2

SIGSTOP isn't something that is "in effect". The signal is delivered, and then the process is in a stopped state. That state is what is in effect. If some signals are generated against the process in that state, then they simply become pending. Signals cannot be delivered to a stopped process. When the process runs again, they get processed according to the signal process mask, and their disposition: ignored signals ignored.

I'm not sure about the order being specified. Only real-time signals have reliable queuing properties. For instance POSIX contains wording like "If there are any pending unblocked signals after the call to sigprocmask(), at least one of those signals shall be delivered before the call to sigprocmask() returns." If, say, a SIGINT and SIGTSTP are both pending, it doesn't specify which is delivered first.

Of course there are special behaviors: being stopped by SIGSTOP doesn't prevent being killed by SIGKILL.

Kaz
  • 7,676
  • 1
  • 25
  • 46
  • What if a signal is delivered multiple times, while the process is stopped? `sigaction()` can set a flag to repeat a signal received while the corresponding signal handler is running. Is there such functionality for a stopped process, or each signal ha a 1-bit flag, and that is that? – Zoltan K. May 17 '22 at 23:18
  • 2
    @ZoltaK Signals can't be delivered when a process is stopped. They can be generated. A signal is like an interrupt line: it goes high and then stays that way, so yes, like a flag. If it is generated again before being delivered, there is no difference. Only the POSIX real-time signals can queue; that's a separate topic, almost. – Kaz May 18 '22 at 04:26