Does an interactive bash process implicitly send any signal other than SIGHUP to its job? By implicitly, I mean not as a consequence of a user's request to send a signal to a job.

It helps to answer Does `disown` apply only to SIGHUP or some or all the signals?

  • the source code of bash does. e.g. interactive bash's SIGHUP handler does, huponexited and interactive bash's pre-termination cleanup does. – Tim Jan 4 at 13:18
  • to bash user, what bash does is implicit. to bash, what the kernel does is implicit. I meant the former. – Tim Jan 4 at 13:20

Yes, there are a number of instances which can be found by searching calls to kill and killpg in jobs.c in the Bash source code.

One example is the handling of stopped jobs when exec is run, or when the shell exits: the shell sends SIGTERM and SIGCONT to all stopped jobs.

  • Thanks. (1) are such cases rare? (2) I don't know how to search for kill in the online hosted repository, even though you might have mentioned it before a little. – Tim Jan 4 at 13:35
  • (1) As rare, or otherwise, as sending SIGHUP. (2) Ctrl+F in your browser works wonders when searching in a single file ;-). – Stephen Kitt Jan 4 at 13:42
  • Does disown make interactive bash not send signals other than SIGHUP to a job? – Tim Jan 4 at 13:50
  • That question is nonsensical. What does disown do? How does Bash know which processes are jobs it is supposed to manage? – Stephen Kitt Jan 4 at 14:07
  • Does this make sense? Does disown apply to SIGHUP only or also to some other signal(s)? – Tim Jan 4 at 14:19

In addition to what Stephen said, it looks like bash sends SIGCONT to stopped processes when you issue a fg or bg command, or otherwise resume a stopped job.  And it sends a SIGSTOP to itself when you issue a suspend command.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.