I looked around the forum and didn’t see this specific issue. I’ve already solved it, so here’s a problem and solution all in one post.
I noticed that dump1090 wasn’t auto starting on a new raspberry pi installation (raspbian, not the FlightAware distro). I had to login and stop then start fadump1090.sh (or run restart). The piaware daemon was running as expected, just the dump1090 process was missing. I had an ethernet connected pi that worked, and a wifi connected pi that wasn’t working. Nothing in the logs indicated an issue with dump1090 starting and it even appeared to have a proper pid file (no actual process though).
After thinking about it for a bit, I noticed that wlan0 was coming up after the system attempted to start dump1090. I realized that dump1090 needs to bind to an interface to listen for piaware connections and the wireless not being connected yet may have been causing issues… I was able to fix it by editing the file “/etc/init.d/fadump1090.sh” to specify $network as a prerequisite.
From the header of fadump1090.sh change:
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
To be:
# Required-Start: $network $remote_fs
# Required-Stop: $network $remote_fs
The above changes the boot daemon order so that the network interface comes up before dump1090 starts. As a result dump1090 is starting properly again. I think this should be added to the package distributed by FlightAware.