Open nsayer opened 7 years ago
Well, that message may be a red herring.
If I run "sudo /opt/PiBakery/startup.sh" it emits that message and works correctly despite it.
Still, it doesn't work when it's run as part of a normal boot.
If you're getting the output in syslog when you boot the Pi, that implies that the scripts are running on boot.
Can you have a look at the contents of the file /boot/PiBakery/everyboot.log
and post the contents here?
It's empty
If I instead put the command that onboot is supposed to run in /etc/rc.local, that works.
Can you connect the Pi to a monitor? At boot time, you'll see a dialog window flash up briefly for everyboot - does this appear at all?
And are you using Raspbian Full or Raspbian Lite?
I'm using Lite.
I don't have the right cable for a monitor (this is a Pi Zero W).
If I modify everyBoot.sh to put an "echo" in front of the command and put it in quotes, then I do see it show up in everyboot.log.
If I used the argument to the command to have it run in the foreground, that works, but then the everyboot script never finishes (which I'm guessing can't be good).
Attempting to run it in the foreground the same way, but adding a "&" to the end of the command doesn't work.
This is really puzzling.
Something is sending my process a SIGTERM.
I've changed my configuration to create a systemd service on first boot rather than try to run the daemon on every boot. That works... but it's still worth figuring out why a long-lived daemon started in a run command block receives a SIGTERM.
If I manually run /opt/PiBakery/runscripts.sh, my every boot block gets run properly. But it doesn't seem to want to happen at actual boot. The only clue I find is the message "console.sh[651]: openvt: Couldn't deallocate console 2" in syslog.