I've read the chapter about the job control in the glibc manual, but I'm wondering what to do with the remaining jobs when the shell is terminated.
I suppose the following steps (following the convention of posix to handle orphaned process groups the first two steps seems obvious):
My problem is what if the jobs survive?
I thought that a chance would be changing their session id to free up the sid and disassociate the process group from the terminal (not sure if that makes sense)
Should I do ioctl(STDIN_FILENO, TIOCSCTTY) to make the session processes lose the controlling terminal and send the signals?
What to do with the tty? Should I launch a login and set it as a new controlling terminal process group of the tty?
I'm still confused and a clue would be appreciated.
send an HUP signal to the jobs with the shell's sid
No need for that. The kernel will send a HUP signal itself when the shell (the session leader) terminates.
send a CONT signal to the stopped jobs with the shell's sid
No need for that. The kernel will send it for you, too ;-)
free up the resource allocated for the job's data structures
No need for that, either. All resources used by a process will be freed up by the kernel when the process terminates.
My problem is what if the jobs survive?
I guess you can SIGKILL them, if that's really a problem. In unix, they're supposed to survive, if they handle SIGHUP.
The "modern" systemd takes a different approach, completely against that spirit, but I would not enter into that ;-)
Notes:
In linux, it's the kill_orphaned_pgrp() from kernel/exit.c which is responsible for sending the HUP+CONT to all stopped jobs from the session, and tty_signal_session_leader() from drivers/tty/tty_jobctl.c, called via tty_vhangup_session() and __tty_hangup() which is resposible for sending the HUP to the processes from the foreground process group.