Sending signals to a process started by systemd

[photomankc2]

I have been trying to get my RaspberryPi ready to operate as a mobile robot. The first major hurdle was to create a process to monitor battery voltage and be able to stop the system if the voltage drops to a critical level. I wrote a daemon process to monitor the I2C ADC that measures the voltage as well as interfaced to custom PIC microcontroller to handle switching the power on and off from both a user button and GPIO pins on the Raspberry. Next step was to make the daemon run on start-up. I added a service file for the process and enabled that in systemd. That works well so the process now starts when the RaspberryPi boots up.

However all the signaling I added to the daemon is broken now. SIGUSR1 was supposed to cause the process to write a file that contained the current battery voltage and ADC output into a file so other processes could read the battery state on demand. That is not working at all, sending any signal at all to the process now causes it to die. SIGUSR2 was to be a way to force a system shutdown. That signal caused the daemon to send a KILL signal to the PIC over a GPIO pin and then used system() to call the poweroff command so the RaspberryPi did a clean shutdown and then the PIC pulls the plug when the GPIO line is released and floats back to it's normal condition. This is also broken and was a second big part of why I made the daemon in the first place.

How can I keep the signals working and start the daemon with systemd? How does it manage to intercept my signals even when I send them straight to the running daemon? All of this works perfectly if I run the daemon from the command line by hand.


So if it is started by systemd and I send SIGUSR1 then this happens:

[robot@robopi-1 ~]$ sudo kill -s SIGUSR1 116

[robot@robopi-1 ~]$ sudo systemctl status powermond
powermond.service - Custom power/battery monitor application for RaspberryPi
Loaded: loaded (/etc/systemd/system/powermond.service; enabled)
Active: failed (Result: signal) since Mon 2013-03-04 15:43:24 CST; 9s ago
Process: 116 ExecStart=/robot/sbin/powermond (code=killed, signal=USR1)


[robot@robopi-1 ~]$ sudo kill -s SIGUSR1 419




If I run it by hand at the command prompt it works and the correct information shows in syslog:

Mar 4 15:45:07 localhost powermond[419]: Starting power monitor process (0.85.0128)
Mar 4 15:45:07 localhost powermond[419]: Battery Status: 7.32V (54.5)
Mar 4 15:45:38 localhost powermond[419]: Signal Caught
Mar 4 15:45:38 localhost powermond[419]: SIGUSR1 - Write output file

[photomankc2]

Found the answer in the code. It was in the boilerplate daemonizing code. Figured it out when I noticed that in addition to the other symtoms that the PID file was not being created which is in the same function as the signal handeling code so it appeared that something was causing that code to abort early. The prime suspect was this bit:

$this->bbcode_second_pass_code('', '
/* Check if parent process ID is set */
/* if so we are already in the background */
if(getppid() == 1)
return;
')

With that section commented out the process behaved as expected and worked identical to the way it worked from the command-line. Since that was borrowed code I'm not entirely sure what the purpose there was. The comments obviously suggest that the intention is to not run the rest of the daemonize function if the parent process was init or in this case systemd but I'm not sure why that would be done. Anyway, the main issue is solved.... the signals are all handled now because it's actually running the signal handling code.