PIGPIOD restart problem

[steuck13]

Greetings,

I've been having a problem when trying to restart my pigpiod daemon after killing the process with a SIGKILL. Usually the first boot happens with no problem at all but after killing the process and trying to restart it, the following error arises:

st-one pigpiod[9877]: 2019-05-06 10:56:10 initMboxBlock: init mbox zaps failed

This is the code for my service:

[Unit]
Description=Daemon required to control GPIO pins via pigpio
DefaultDependencies=false

[Service]
EnvironmentFile=/etc/default/config_file
ExecStart=/usr/local/bin/pigpiod -n localhost -n 127.0.0.1
ExecStartPost=/bin/bash -c 'pigs proc $SCRIPT'
ExecStartPost=/bin/systemctl start leds_service
ExecStop=/bin/bash -c "kill -TERM -- $(pidof pigpiod)"
Type=forking
SyslogIdentifier=pigpiod
Restart=always
RestartSec=2

And this is my setup:

• Raspbian 4.14.98-v7+
• Raspberry Pi 3 Model B Rev 1.2

A few days ago I found a post where someone suggested this was a memory problem. But even after terminating the previous running daemon? After that, I tried to change de memory allocation mode to PMAP, however I couldn't say if the problem persisted or not because the whole system froze when the daemon was killed.

Any suggestions?

Ty

[steuck13]

I added the following line:

gpioSetSignalFunc(SIGKILL,terminate)

to pigpiod.c and this error don't happen anymore. However, since so many signals are handled by terminating, my program is in a loop right now.

[SlySven]

That is bad in multiple ways! 😱

You should only use SIGKILL (kill -9 <pid>) if all other things fail - it may well cause problems as the program which get gets it cannot do anything to clean up - it just immediately suicides.

Also - by definition - SIGKILL cannot be caught/handled/ignored (https://en.wikipedia.org/wiki/Signal_%28IPC%29#SIGKILL) {and it is one of the signals (the other is SIGSTOP) that an application should not try to do those things on - anyhow it will not be permitted by the underlying system - I did try to enforce this in a failed PR #58 but that is another story and that restriction did not - I think - ever get into the codebase}...

[steuck13]

We gave up forking and it solved our problems. This daemon seems to have some issues with it, plus the way it handle signals probably doesn't help. I'll take a look into the issue you mentioned, thank you for your answer.

[joan2937]

I shall not be making any changes in this area.