Skip to main content
Commonmark migration
Source Link

This happens even though os.system('sudo pigpiod') returns 0, there are no exceptions, and a .sleep(1) was executed "just to make sure".

 
  • The FIRST time I run it after boot, it is always successful.
  • if pigpiod was already running, then it is always successful.
  • If I run a few seconds after a failure, it seems to always fail again.
  • It seems if I wait a LONG TIME after a failure, like several minutes, then run it again, it is more likely to be successful.

This happens even though os.system('sudo pigpiod') returns 0, there are no exceptions, and a .sleep(1) was executed "just to make sure".

 
  • The FIRST time I run it after boot, it is always successful.
  • if pigpiod was already running, then it is always successful.
  • If I run a few seconds after a failure, it seems to always fail again.
  • It seems if I wait a LONG TIME after a failure, like several minutes, then run it again, it is more likely to be successful.

This happens even though os.system('sudo pigpiod') returns 0, there are no exceptions, and a .sleep(1) was executed "just to make sure".

  • The FIRST time I run it after boot, it is always successful.
  • if pigpiod was already running, then it is always successful.
  • If I run a few seconds after a failure, it seems to always fail again.
  • It seems if I wait a LONG TIME after a failure, like several minutes, then run it again, it is more likely to be successful.
added 95 characters in body
Source Link
uhoh
  • 552
  • 5
  • 20

It turns out that this sluggishnesssluggishness in the pigpiod DAEMON is realDAEMON's status is real. It's not a problem in the script.

I saw this by accident while trying to stop and then restart pigpio while debugging a DHT22 scriptDHT22 script.

It turns out that this sluggishness in the pigpiod DAEMON is real. It's not a problem in the script.

I saw this by accident while trying to stop and then restart pigpio while debugging a DHT22 script.

It turns out that this sluggishness in the pigpiod DAEMON's status is real. It's not a problem in the script.

I saw this by accident while trying to stop and then restart pigpio while debugging a DHT22 script.

Source Link
uhoh
  • 552
  • 5
  • 20

This is a partial answer; I am going to try to understand further why this is so. If someone is able to explain further that would be wonderful.

The behavior described by the OP (in this case, me) is:

This happens even though os.system('sudo pigpiod') returns 0, there are no exceptions, and a .sleep(1) was executed "just to make sure".

  • The FIRST time I run it after boot, it is always successful.
  • if pigpiod was already running, then it is always successful.
  • If I run a few seconds after a failure, it seems to always fail again.
  • It seems if I wait a LONG TIME after a failure, like several minutes, then run it again, it is more likely to be successful.

It turns out that this sluggishness in the pigpiod DAEMON is real. It's not a problem in the script.

I saw this by accident while trying to stop and then restart pigpio while debugging a DHT22 script.

Here's some text from the Pi's terminal. After the killall, pigpiod can not be started between 21:25:07 and 21:25:54.

The message:

"bind to port 8888 failed (Address already in use) Can't initialise pigpio library"

appears when trying to start it, but

"no process found" 

appears when trying to kill it.

So for almost a minute, the DAEMON is a zombie (so to speak).

This means that the idea of quickly turning it off and then on again is a bad one. Instead, if the OP (me) really wants to do this with Python, the script has to honor this transient zombie status and not just start and stop it willy-nilly.

pi@raspberrypi:~ $ pidof pigpiod
2498
pi@raspberrypi:~ $ sudo killall pigpiod
pi@raspberrypi:~ $ pidof pigpiod
pi@raspberrypi:~ $ sudo pigpiod
pi@raspberrypi:~ $ sudo killall pigpiod
pi@raspberrypi:~ $ sudo pigpiod
pi@raspberrypi:~ $ 2018-03-12 21:25:07 initInitialise: bind to port 8888 failed (Address already in use)
Can't initialise pigpio library
pidof pigpiod
pi@raspberrypi:~ $ pidof pigpiod
pi@raspberrypi:~ $ sudo pigpiod
pi@raspberrypi:~ $ 2018-03-12 21:25:24 initInitialise: bind to port 8888 failed (Address already in use)
Can't initialise pigpio library
sudo pigpiod
pi@raspberrypi:~ $ 2018-03-12 21:25:37 initInitialise: bind to port 8888 failed (Address already in use)
Can't initialise pigpio library
sudo killall pigpiod
pigpiod: no process found
pi@raspberrypi:~ $ sudo killall pigpiod
pigpiod: no process found
pi@raspberrypi:~ $ sudo pigpiod
pi@raspberrypi:~ $ 2018-03-12 21:25:54 initInitialise: bind to port 8888 failed (Address already in use)
Can't initialise pigpio library
sudo killall pigpiod
pigpiod: no process found
pi@raspberrypi:~ $ pidof pigpiod
pi@raspberrypi:~ $ sudo pigpiod
pi@raspberrypi:~ $ pidof pigpiod
3030
pi@raspberrypi:~ $ ^C
pi@raspberrypi:~ $