steps to terminate a shell

Question

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):

• send an HUP signal to the jobs with the shell's sid
• send a CONTINUE signal to the stopped jobs with the shell's sid
• free up the resource allocated for the job's data structures

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.

Answer 1

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.

Answer 2

• Should I launch a login and set it as a new controlling terminal process group of the tty?

I read up and I think the answer should be no.

For a character based terminal, the root process (initd/systemd/launchd etc) forks and execs getty for the preconfigured terminals or at a specific event. Getty opens the terminal files for read/write and associates the std file descriptors to the terminal, sets a simple environment from a configuration file and prompts for a username, then execs login for that username. Login changes the ownership and permission rights for the terminal, changes the persona of the process (effective and real uid, gid, supplement groups), and execs a login shell When a shell terminates, its parent process get notified by a sigchd, and relaunches getty... So the tty initialization/destruction is not a task for the shell..

Yet not sure on how to treat the survived process groups..