Processo sendo enviado SIGINT quando iniciado usando o Upstart

Question

Eu tenho um aplicativo Linux que abre vários dispositivos seriais ( /dev/ttyUSB X) e lê / escreve a partir deles. Quando eu corro de um prompt de comando (Ubuntu 10.04, bash) funciona perfeitamente.

$sudo ./my_program /dev/ttyUSB0   #sudo for permissions on the device

Eu quero que este programa seja executado na inicialização e seja respawned se ele morrer - então eu coloquei na configuração do Upstart ( /etc/init/* ) e chamei " my_service ".

Quando reinicializo a máquina, o my_service é executado e o my_program é executado. No entanto, depois de alguns segundos (ao redor, quando está abrindo o ttyUSB e lendo deles) meu processo recebe um SIGINT. Eu não pode imaginar de onde está vindo. Não é um problema de permissões nos dispositivos, eles abrem () bem e alguns bytes são transferidos OK. Usando waitsiginfo() eu estava pode obter um si_code de 0x80 ou SI_KERNEL . Então eu sei que não é vindo de outro processo, mas do próprio kernel. Ninguém tem aperte CTRL - C ou ALT - CTL - DEL no console - por que é o envio do kernel eu um SIGINT ?

Pior, meu programa sai apropriadamente baseado neste sinal - é Respawned por Upstart, e é prontamente SIGINT'ed novamente! Existe algum maneira de descobrir de onde este sinal é originário e por quê? É Existe algum nível de depuração do kernel que poderia ser ativado para lançar alguma luz sobre isso? Por que o comportamento diferente quando iniciado por Upstart vs. manualmente de bash ?

    

Answer 1

Problema resolvido, apesar de ser um erro de programação e não relacionado ao Upstart. O programa abre o dispositivo ttyUSB para entrada bruta (não-canônica), mas não estava limpando o sinalizador ISIG em termios. Sempre que um caractere "CTRL-C" (0x02) foi recebido, o kernel gerou o SIGINT e o enviou para o programa. Esse problema não estava acontecendo no bash porque as configurações do termios são persistentes em um arquivo, e algo deve ter aberto o tty e limpado o bit ISIG antes que meu programa fosse executado. Isso não ocorreu ao executá-lo diretamente do Upstart. Eu ainda gostaria que houvesse uma maneira melhor de registrar / depurar sinais, o ptrace é apenas metade da resposta!

    

Answer 2

Um programa é enviado SIGINT quando é colocado em segundo plano (pense ^ Z). Normalmente, as coisas que vão viver enquanto os daemons capturam o sinal e sobrevivem.

Verifique se você pode iniciar o programa a partir de um shell interativo e colocá-lo em segundo plano por ^ Z. É bem possível que também morra.

Se isso for a resposta, você tem 2 possibilidades. Se for o seu programa, você pode interceptar o SIGINT. Se você não tiver acesso às fontes, ou não quiser gastar mais tempo na codificação desse recurso, ou executar o programa em algumas versões do Java VM com problemas com sinais, envolva seu programa em um script que use screen para iniciar e executar seu programa. Dessa forma, screen entra em segundo plano, mas seu código é levado a pensar que está sendo executado em primeiro plano da sessão interativa.