Torizon: How to reboot host by docker container

I have an application that need to reboot entire host if a special case happen on my code. Then I need to reboot host by docker container, is there a way to do that inside container?
I am runing on a alpine node docker container and torizon core 4.

Greetings @eduardopilla,

Let me start by saying that this is certainly possible. Though most methods I know of are a little on the “hacky” side. Since it’s unusual to let a container reboot the entire system.

Nonetheless let me share what I know. So the obvious method would be to bind mount certain system files into the container that can be written to and trigger reboot. More details found in this external thread: Restarting host from docker container - Stack Overflow

The other method that doesn’t require writing system files would be as follows. So by running a container with --network=host it’s actually possible to SSH to the host system’s terminal from the container via localhost. From there you can then just issue a reboot on the command line over this SSH connection.

Though the second method requires you to run the container with host network stack so it may be undesirable compared to the first method depending on your use case.

There’s probably other methods as well but these are the most obvious ones to me.

Best Regards,
Jeremias

Thanks @jeremias.tx, I am working on this solution with SSH, but I am getting permissions issues with ‘reboot’ comand. I added the following line to file /etc/sudoers
torizon ALL=NOPASSWD:/sbin/reboot

But the error persist.

Thanks in advanced.

I believe even with that line in the sudoers file reboot the command itself requires root/sudo permissions. Reboot is a kind of special command in that sense since outside of usual permissions it explicitly checks itself if the user is running with either root or sudo.

You can pipe a sudo through SSH I believe. With that line you just need to run “sudo reboot” but due to your addition to sudoers a password is not actually required.

Best Regards,
Jeremias

You may use dbus for this, sharing the dbus filesystem entry point in the container.
Check our samples here:

Another point, for double check I would to add some kind of solution like a cron job, to reboot my device once per day, I will use it if for some reason dbus falled. I was searching but not found a solution for torizon.

Hi @jeremias.tx and @eduardopilla,

The solution for that in a more feasible way involves the usage of dbus.

We have a sample for this here in our Torizon Samples GitHub repo, in Python.
Please check if that helps.

Best regards,
André Curvello

We are trying to do the same on our setup:

  • Colibri iMX8X v. 1.0D module
  • Aster board v. 1.1B
  • TorizonCore os

We manage to reboot the host from within the container using python and the dbus library.
However it is not a clean reboot (i.e. not like when you use reboot from the command line). It doesn’t seem to ‘gracefully’ reboot/shutdown, properly ending all the running services first. It seem to have not had time to properly clean up docker, its networks and ports.
When it restart some of the containers seem to be still ‘running’ , and if you try to restart the containers it complains that the ports are still in use.
However all of this doesn’t happen if you reboot from command line.
We tried using both org.freedesktop.systemd1 (as per github example) and org.freedesktop.login1 but the have the same result.
Has anyone been able to reboot/shutdown ‘gracefully’ using dbus?

Dear @morlandi, how are you?

As this topic was tagged as solved, can you please open a new thread for your question? In the meantime, one solution could be to create a systemd service that stops all containers from running before shutdown like it has been done here: Container limit? - #14 by gclaudino.tx

Thanks a lot!

Best regards,

Will do - didn’t want to open another thread, as it was connected to this one…

I’ve tried your suggested solution, but the problem persists. I think the issue is that when the reboot is called using dsub, is not actually doing the same thing as rebooting from shell - i.e. it feels like it’s power-cycling straightaway without calling the proper reboot/poweroff procedure.