rsyslogd como líder de sessão

Question

Atualmente estou lendo Programação Avançada no ambiente Unix. Em um dos exercícios, diz:

The only user-level daemon that isn't a session leader is the rsyslogd process. Explain why the syslogd daemon isn't a session leader.

No entanto, quando eu vou verificar isso, eu vejo que no meu sistema (Linux 4.4), na verdade, é um líder de sessão (porque PID == SID):

UID        PID  PPID  PGID   SID  CMD
syslog    1171     1  1171  1171  /usr/sbin/rsyslogd -n

Isso é uma coisa do sistema? Algumas das informações contidas neste livro estão um pouco desatualizadas agora que todos participaram do movimento systemd, ao passo que ele fala principalmente sobre o clássico System V init. Ou talvez eles simplesmente mudaram como isso funciona?

O livro claramente quer mostrar por que ele é diferente, então se alguém sabe por que historicamente ele não costumava ser um líder de sessão, e por que é agora, isso seria excelente.

    

Answer 1

Editar

Na verdade, eu dei uma olhada em um antigo sistema 10.04 do Ubuntu que tinha o rsyslogd 4.2.0 rodando.

Esse não chamou setsid() (então, herdou o sid do processo que o executou), mas o fez (aqui de strace output):

 19391 open("/dev/tty", O_RDWR|O_LARGEFILE|O_CLOEXEC) = 0
 19391 ioctl(0, TIOCNOTTY)               = 0

Para desanexar do terminal.

Analisando o código-fonte , ele faz isso somente quando HAVE_SETSID não está definido. Obviamente, o Linux tem setsid() e tem tido por décadas, então há algo errado.

Agora, olhando mais para a fonte, é apenas o procedimento de compilação que nunca define HAVE_SETSID , pois não verifica o suporte de setsid() em primeiro lugar.

O erro (um erro de digitação: setsid escrito setid no arquivo autoconf) foi corrigido em 2013 (lançado pela primeira vez no rsyslogd 7.5.3).

(btw, consulte a seção TODO sobre HP / UX no código antigo que mostra que os autores já haviam percebido que havia algo errado (mas não investigaram até muito mais tarde)).

Mantendo a resposta original abaixo, pois é possível encontrar informações úteis.

Um palpite:

Se você é um líder de sessão e abre um dispositivo tty sem o sinalizador O_NOCTTY , você se torna o processo de controle de um terminal.

É por isso que ao tentar executar um aplicativo (que não foi projetado para ser executado como um daemon) para ser executado como um daemon, é recomendável fazer outro fork após o setsid() antes de executá-lo para garantir que o processo não se torna inadvertidamente um controlador de terminal se, por algum motivo, ele abrir um dispositivo tty.

syslogd normalmente abre dispositivos tty para enviar mensagens de usuários, então pode ser por isso que seu livro diz que o syslogd não é um líder de sessão, descrevendo o comportamento de implementações syslogd de um tempo em que o sinalizador O_NOCTTY não existia essa bandeira existe pelo menos desde o final dos anos 80).

A outra abordagem é para o syslogd certificar-se de que todos os arquivos abertos sejam abertos com O_NOCTTY, que é provavelmente o que seu rsyslogd (nada a ver com systemd ) possui.