Meu processo foi morto mas não consigo entender o aviso do kernel

Question

Eu tenho um aplicativo personalizado em execução em uma configuração x86 incorporada (construída usando buildroot e uClibc). A aplicação correu bem, mas esta manhã, quando voltei a trabalhar, descobri que o meu processo tinha sido eliminado e o seguinte resultado no meu terminal

SAK: killed process 1008 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1009 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1011 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1012 (CX_SC3): fd#4 opened to the tty

Agora, CX_SC3 é o meu processo - ele tem vários segmentos, um dos quais abre /dev/ttyS0 para enviar mensagens por um modem de rádio. O número fd é 4 para a porta serial. O que eu não entendo é

1. O que o SAK significa
2. O PID listado acima deve se referir a um processo que foi eliminado pelo meu aplicativo, pois há apenas uma instância do meu aplicativo em execução por vez. É possível que esses PIDs sejam realmente meus IDs de encadeamento (já que meu aplicativo executa 4 encadeamentos sempre).
3. Se meu aplicativo matasse outros processos, por que meu aplicativo também foi eliminado?
4. O que a parte opened to the tty significa? De alguma pesquisa, isso sugere que isso tem algo a ver com um caractere de interrupção enviado para o tty que usei para iniciar o programa.

Tenho certeza de que o acima é bastante óbvio quando você é um guru do Linux, mas estou com dificuldades - alguém pode sugerir quais eventos poderiam ter levado à seguinte saída? Minha configuração incorporada é muito pequena, usa busybox e executa vsftpd e muito pouco além do meu aplicativo personalizado. É vital que meu aplicativo seja robusto, portanto, se alguém puder sugerir / adivinhar que sequência de eventos poderia ter causado o acima, ficarei muito grato.

EDIT: Em resposta ao comentário abaixo, se isso ocorrer porque um SAK foi detectado, há algo que possa acidentalmente acionar isso? É possível que algo sendo lido na porta serial tenha provocado isso? Além disso, como posso encontrar a combinação SAK para o meu sistema? Eu não tenho um arquivo rc.sysinit ou rc.local em qualquer lugar no meu sistema de arquivos raiz.

ATUALIZAÇÃO: Consegui fixar esse evento no ponto em que minha máquina host é encerrada. Eu tenho um cabo serial entre minha máquina host e meu dispositivo de destino que eu uso para enviar dados seriais para o destino incorporado. Quando deixo o alvo em execução, mas encerro o host, meu aplicativo é eliminado conforme descrito acima. Quando eu desconectar o cabo serial antes de desligar minha máquina host, meu aplicativo não é interrompido e executado normalmente. Esse comportamento acontece mesmo depois de eu ter realizado

echo 0 > /proc/sys/kernel/sysrq

como recomendado.

    

Answer 1

O SAK neste caso realmente significa Chave de atenção segura . A mensagem que você está vendo é uma mensagem do kernel definida em drivers / tty / tty_io. c . O SAK é uma combinação de teclas que garante login seguro para um usuário no console. No Linux, o SAK garante isso matando todos os processos anexados ao terminal em que o SAK é chamado. Espera-se que init reinicie o processo de login confiável como getty seguido por login ou servidor X com gerenciador de exibição .

Os PIDs listados são de fato PIDs de threads de sua aplicação CX_SC3 que foram mortos pelo SAK.

fd#n opened to the tty significa que o processo / thread que foi morto tinha o descritor de arquivo n aberto no terminal no qual o SAK foi invocado.

No Linux há duas maneiras de invocar o SAK :

1. Por meio da chave mágica do SysRq - normalmente Alt + SysRq + K (terminal virtual) ou Quebra K (console serial). Este não é o seu caso, uma vez que você já tentou desativar a magia SysRq por echo 0 > /proc/sys/kernel/sysrq e enviar a seqüência Break K por acidente é improvável.

2. Através de uma sequência de teclas definida (terminal virtual) ou do sinal de interrupção (console serial). A disponibilidade do SAK em um console serial é controlada por setserial .

O sinal de quebra em uma linha serial é o envio contínuo de valores de espaçamento durante um tempo maior que o caractere tempo de envio (incluindo bits de início, parada e paridade). No seu caso, é altamente provável que a condição do sinal Break seja exibida durante o desligamento da máquina host. Por favor, tente desligar o SAK na sua porta serial no dispositivo de destino por setserial :

setserial /dev/ttyS0 ^sak

Você pode verificar o status da funcionalidade SAK na porta serial em setserial -g /dev/ttyS0 . Quando ativado, ele mostrará SAK após Flags: . Para configuração automática da opção após a inicialização, consulte os scripts de inicialização que, nos sistemas BusyBox, geralmente são /etc/init.d/rcS e /etc/rc.d/S* ou verificam /etc/inittab para outras possibilidades.

    

Answer 2

Consegui resolver o problema com a ajuda da resposta de pabouk. A solução baseada em código que finalmente descobri que permite que o sinal SAK seja definido / não configurado na porta serial ao abrir usando a API do userspace pode ser encontrado em stackoverflow aqui Como posso desabilitar a opção SAK da porta serial no Linux usando a API userspace?