Process being sent SIGINT when started using Upstart

Question

I have a Linux application which opens up several serial devices (/dev/ttyUSBX) and reads/writes from them. When I run it from a command prompt (Ubuntu 10.04, bash) it works perfectly.

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

I want this program to run at startup, and be respawned if it dies - so I put it into the Upstart config (/etc/init/*) and called it "my_service".

When I reboot the machine, my_service executes and my_program runs. However, after a few seconds (right around when it's opening up the ttyUSB's and reading from them) my process receives a SIGINT. I cannot figure where it's coming from. It's not a permissions issue on the devices, they open() fine and a few bytes get transferred OK. Using waitsiginfo() I was able to get a si_code of 0x80, or SI_KERNEL. So I know it's not coming from another process, but from the kernel itself. Nobody has hit CTRL-C or ALT-CTL-DEL on the console - why is the kernel sending me a SIGINT?

Worse, my program appropriately exits based on this signal - is respawned by Upstart, and is promptly SIGINT'ed again! Is there any way to figure out where this signal is originating from and why? Is there some level of kernel debugging that could be enabled to shed some light on this? Why the different behaviour when started by Upstart vs. manually from bash?

Answer 1

Problem solved, though it was a programming error and not related to Upstart. The program opens up the ttyUSB device for raw (non-canonical) input, but it was not clearing the ISIG flag in termios. Whenever a "CTRL-C" character (0x02) was received, the kernel generated the SIGINT and sent it to the program. This issue wasn't happening from bash because termios settings are persistent on a file, and something must have opened the tty and cleared the ISIG bit before my program was executed. This did not occur when running it directly from Upstart. I still wish there were some better way to log/debug signals, ptrace is only half the answer!

Answer 2

A program is sent SIGINT when it is put into background (think ^Z). Normally things that are going to live as daemons trap the signal and live on.

Verify, if you can start the program from an interactive shell and then put it into background by ^Z. It is quite possible it will die too.

If that proves to be the answer, you have 2 possibilities. If it is your program, you can trap SIGINT. If you do not have access to the sources, or do not want to spend extra time on coding this feature, or you run the program on some versions of Java VM that have problems with signals, then wrap your program in a script which uses screen to start and run your program. In that way screen goes into background, but your code is fooled into thinking it's running in foreground of interactive session.