davidferguson / pibakery-raspbian

The changes made to Raspbian to support PiBakery
150 stars 12 forks source link

daemon launched by run command block receives SIGTERM #33

Open nsayer opened 7 years ago

nsayer commented 7 years ago

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.

nsayer commented 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.

davidferguson commented 7 years ago

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?

nsayer commented 7 years ago

It's empty

nsayer commented 7 years ago

If I instead put the command that onboot is supposed to run in /etc/rc.local, that works.

davidferguson commented 7 years ago

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?

nsayer commented 7 years ago

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.

nsayer commented 7 years ago

Something is sending my process a SIGTERM.

nsayer commented 7 years ago

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.