I've been using the Large-Image withe Node-Red for a long time now and previously been able to Reboot or Shutdown my RPi using and Exec node. For Reboot the command has been "reboot #" and "poweroff #" to shutdown.
I have just noticed that neither command now works with an Error: 126. Is there a new command? Is this a permissions thing?
It's all worked so well for so long I've only needed to do updates so perhaps missed some changes. Thanks for any info.
I have been using a similar technique running shutdown in a Node-RED Exec node and yes error 126 is a permission problem. One can get more information on errors by connecting all three outputs of the exec node to a debug node which then shows shows the error output stream.
The have not said what machine or OS version number you are using but I saw in an earlier post you have a Raspberry Pi 4 but not which version which makes a definitive diagnosis of the problem more difficult. I however expected and saw exactly the same problem with a Pi 4 rev 1.5 using shutdown when I changed from a Venus OS 2.82 to the new candidate version series 2.90 currently 2.90~24 which supports the Pi 4 much better so you may have done the same.
The cause in my case is that node-red no longer runs as root but runs under a new user nodered in Venus OS v2.90. This is much more secure as single mistake in an exec node command running as root could brick some machines.
Use of commands such as shutdown, poweroff and reboot depend on being run as root otherwise any user could shutdown a multi-user machine.
The solution does not seem to be as simple as just changing permissions, they have to actually be run by root. The underlying Linux distribution in the Venus OS is openembedded-core Dunfell. As the name implies it is optimised for embedded systems with minimal utilities so users who have used desktop distributions such as Debian and its derivatives Ubuntu and Mint, like me, find it very different. It uses BusyBox so some common commands have reduced functionality and many are missing. There is no sudo for example so the normal techniques to allow certain programs to run as root under sudo without asking for a password do not work.
I am still looking for a more elegant solution but I have currently resorted to a quick fix of having a program running under root every few seconds which checks for the presence of a file whose contents contain the command line and run it before deleting the file. This entails a delay which is acceptable, even desirable, for shutdown activities and allows them to be cancelled. I am currently using a cron job run every minute. I can give more details if anyone asks.
If anybody has found a more elegant solution to the problem I would really like to hear!
openembedded can build all kind of things, and Venus does build the non-busybox versions as well e.g. as optional packages. After setting up opkg, just run:
opkg install packagegroup-replace-busybox
sudo will be available by default in the large image as well in the next candidate version.
I have just installed kwindrem 's shutdown script which now allows me to shutdown from the menu, is there a way use dBus to shutdown and reboot the Pi from node-red?
My solution to the shutdown problem from Node-RED now it is no longer running as root does not use dBus directly. As I said above it works by having a short program running under root which checks frequently for the presence of a file which is in the nodered area and can be created within Node-RED. It assumes the file contains a single line which is a valid command, runs it as root and deletes the file ready for another command.
I initially used a Cron job but I now have an even simpler program using a sleep command which does the checking and uses far less processor than I expected, barely noticeable.
A very important feature of the Venus OS is the ability to run programs in the user area during the initialisation process described at https://www.victronenergy.com/live/ccgx:root_access which describe the hooks which are built in to allow a script to be run as root which resides on /data and hence survive a version update. To quote
"If the files /data/rcS.local or /data/rc.local exist, they will be called early (rcS) and late (rc) during startup. These scripts will survive upgrades and can be used by customers to start their own custom software."
So my checking script is started as a separate process within /data/rc.local but still runs as root which is what I need. @Kevin Windrem may use the same file to start his excellent utilities and may wish to comment as what follows may conflict.
The three commands I use are shutdown -r 1 & , shutdown -h 1 & and shutdown -c now so the halt and reboot commands can be cancelled within one minute by the shutdown -c now. The command svc -t /service/node-red should still restart node-RED but I have not yet checked. The script looping every second is:
#!/bin/sh # /data/every-second.sh # FILE=/data/home/nodered/.node-red/scripts/cmdfile while true do if test -f "$FILE"; then cmd=$(cat "$FILE") echo "$(date) - Running $cmd" >> /data/root_command_log rm "$FILE" eval "$cmd" fi sleep 1 done
My rc.local file does a lot more but the relevant parts are
#!/bin/sh # Contents of /data/rc.local # ....... # Run timer loop as separate process sh /data/every-second.sh & # ..... exit 0
Just use an Exec node to echo the commands to /data/home/nodered/.node-red/scripts/cmdfile eg echo "shutdown -r 1 &" > /data/home/nodered/.node-red/scripts/cmdfile will shutdown after 1 minute unless you send a cancel command in that time
I tend to write up what I do to avoid forgetting - I suspect links to web information are frowned on but my profile might prove interesting!
