Hi,
we are running shutdown command, and it takes sometimes 30 seconds for the device to shut down.
this is the command that we are running:
dbus-send --system --print-reply --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.PowerOff
are we suppose to do something else? looks like our SOM (Variscite) is still on, for some random long time.
Daniel.
Hi Daniel, just to clarify your statement, you said “looks like our SOM (Variscite) is still on, for some random long time”…Does that mean in addition to the 30 seconds or so that you reported to shut down? And also, I understand you say it is random, but can give any estimate? Is it 1 minute more, 5 minutes more, an hour more? …And finally, after that random time, does the device indeed properly shut down?
hi, thanks for the reply.
it takes around 45~ seconds in average, it never takes more than 1 minute and 20 seconds.
At the end, the device properly shutdown.
Hi
Have you tried using the supervisor to shutdown the device?
There’s an optional force parameter to it too. Would love to understand more about why you are using dbus-send - and what are the times you see when powering down using the supervisor API
@mellerdaniel Did you have chance to try using the supervisor as Anuj suggested? Let us know if you still need some assistance with this! 
sorry, was away for awhile.
this still doesnt answer our requirements - it is really slow, it closes all the services and takes too much time.
i would like to have like a super fast shutdown, something like calling:
“systemctl --force poweroff” or “systemctl --force --force poweroff” but from one of the services.
Is that possible?
Well, if you must issue systemctl --force poweroff on the host, having found all other solutions, includign DBUS and a POST to the Supervisor API inadequate, then the only other option is to SSH into the host from the container and issue the command.
For this to work, you’ll need to generate a keypair and put the public key into config.json on the host followed by a reboot (e.g. Configuration - Balena Documentation). Then in from your container containing the matching private key and openssh client, just run ssh -p 22222 root@{{ bridge-ip }} systemctl --force poweroff.
Just to follow-up on yet a different way and assuming your device type has the SYSRQ interface available and you are using a privileged container, you could use it to sync the disks and reboot, which is way cleaner than the force reboot approach that would very likely cause data loss. You can check whether:
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger
when executed from the container causes the expected behaviour.