I would like to boot into a python app. My python app has the excellent pigpiod daemon as a prerequisite. I am using Busybox init process. I have a pigpiod launch script /etc/init.d/SXpigpiod and my python application launch script /etc/init.d/SYmyapp (X is smaller than Y).

The problem I encounter is this - pigpiod immediately forks thus init moves on swiftly, however it takes some time before pigpiod is actually responsive. If myapp is called by init too soon, it's game over because python pigpio module cannot connect to pigpiod. I know it is a simple race condition because if I run /etc/init.d/SYmyapp from console everything is fine. Also, making X as small as possible and Y as large as possible, thus ensuring that several other init tasks are executed in between (notably S40network), resolves the problem. This is not good enough though, I need to minimise cold boot time and most of the other init tasks will disappear eventually. I have tried looping inside myapp init script waiting for pigpiod to start responding, like this:

while [ "$(pigs pigpv 2>&1 >/dev/null)" = 'socket connect failed' ]
  #echo "pigpiod down"
  sleep 0.1

This appears to block pigpiod from ever loading. Implementing a similar thing inside python app also appears to block pigpiod from loading:

while not pigpio.pi().connected:

Is there a way to ensure that myapp is started as soon as pigpiod is responding, without blocking pigpiod initilaisation?

  • You really shouldn't use deprecated SysV init scripts anymore on new projects. it's no wonder that run into trouble. – Ingo Jul 4 '19 at 9:37
  • This is exactly the kind of problem that systemd was designed to solve. If you don't want to use it, just throw in a long enough delay (sleep 10) and be done with it. – Dmitry Grigoryev Jul 4 '19 at 9:50
  • Thanks for taking the trouble to look at this. I have a reason for using Busybox init (not even sysvinit). Currently systemd requires glibc in Buildroot which I would like to avoid. Busybox init (default in Buildroot) allows me to use musl instead resulting in more compact code which should translate into shorter cold boot time. I think the problem is with pigpiod forking too early - before it is fully functional. I am not sure systemd would deal with this any better. – Evgueni Jul 4 '19 at 11:19
  • I have not found a way to resolve this with pigpio, but I have now sidestepped the problem by replacing pigpio functions that I needed (rotary encoder and hardware pwm) with native linux drivers via dtoverlay=rotary-encoder,.. & dtoverlay=pwm-2chan,... statements in config.txt. Cold boot time is now 10s, half of what it was with systemd and pigpiod. – Evgueni Jul 9 '19 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.