Do ponto de vista de um sistema operacional, todo programa em execução é um processo. Quando o kernel é iniciado, ele inicia um processo, principalmente init . Se é SYSV init ou systemd não é relevante para esta discussão, um processo é iniciado. Todos os outros programas são iniciados por outro processo. Isso cria um relacionamento entre os processos, o processo inicial (a.k.a. "pai") e o processo iniciado (a.k.a. "filho"). O kernel está ciente dessas relações.
Quando um processo sai no Linux / Unix, o kernel envia para todos os seus processos filhos o número de sinal 15 (SIGTERM). Ele pode ser capturado pelo processo e o processo deve fazer o que for preciso para sair de forma segura. Você também deve saber o número do sinal 9 (SIGKILL). Este sinal não pode ser capturado pelo processo: o kernel pára o processo sozinho.
Veja este pstree :
init─┬─acpid
├─atd
├─cron
├─dbus-daemon
├─dhclient
├─dhcpd
├─exim4
├─6*[getty]
├─lwresd───6*[{lwresd}]
├─named───6*[{named}]
├─nmbd
├─portmap
├─rpc.statd
├─rsyslogd───2*[{rsyslogd}]
├─smbd───2*[smbd]
├─sshd───sshd───bash───screen───screen───bash───pstree
└─udevd───2*[udevd]
Você pode ver que pstree é um processo filho de bash e bash um processo filho de screen . Quando saio da máquina, o bash após sshd sai e o kernel envia um sinal 15 para o processo filho screen . MAS, screen não reage a isso. Portanto, o novo processo pai de screen é agora o processo número 1 ( init ). Veja neste pstree :
init─┬─acpid
├─atd
├─cron
├─dbus-daemon
├─dhclient
├─dhcpd
├─exim4
├─6*[getty]
├─lwresd───6*[{lwresd}]
├─named───6*[{named}]
├─nmbd
├─portmap
├─rpc.statd
├─rsyslogd───3*[{rsyslogd}]
├─screen───bash
├─smbd───2*[smbd]
├─sshd───sshd───bash───pstree
└─udevd───2*[udevd]
Na verdade, é isso que acontece quando você desanexa o screen ( ctrl + a - d ). Portanto, todos os subprocessos de screen continuarão sendo executados após a desconexão ou desanexação de screen . Quando você executa um processo sem screen ou tmux , ele recebe um sinal SIGTERM.