Is there any way to power off the toradex board through rtc wake command inside from the docker container with
rtcwake -d /dev/rtc1 -m off -s 60?
There is no access of systemd from inside the container. so i am not being able to achieve my intermittent operation. I have achieved sleep mode using “rtcwake -d /dev/rtc1 -m mem-s 60” from inside the container but there was a problem and also little bit power consumption in mem mode. so i want to use “off” mode, which works perfectly when i run it from Host-level script:
Run a script on the host system that monitors for a signal from the container (e.g. via a shared volume or network communication) and executes the rtcwake command when triggered.
but i want to achieve the rtcwake off command from inside the container not from calling any host-level script. Thank you!
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Based on the context provided, executing the rtcwake -d /dev/rtc1 -m off -s 60 command directly from within a Docker container is not feasible due to the inherent limitations of Docker containers. These limitations include restricted access to hardware resources and the absence of systemd, which are necessary for executing such commands.
The recommended approach is to use a host-level script that listens for a signal from the container and executes the rtcwake command when triggered. This method effectively bypasses the container’s isolation but does not meet your requirement for direct execution within the container.
While you may consider adjusting Docker’s security settings or using privileged mode to potentially allow such operations, these approaches could introduce security risks and are not guaranteed to work. Therefore, the most reliable solution remains the use of a host-level script to manage the power-off operation.
Please, also check if these links can help you solve your problem:
Hi @makasujan
I am not too familiar with rtcwake but what you could do is to mount all necessary binaries and libraries from the host system into the docker container. Then when you are calling rtcwake inside your container it actually calls it “outside” of the container.
But I am not a huge fan of this solution, as the AI Bot mentioned, this comes with some security issues. Most likely you need to run your container in priviledged mode and who knows what modules you need to mount into the container just to perform this task and this can open the doors for other security issues.
I did this to perform system commands at the host system from a docker container:
I created a systemd service which periodically checks for a specific file and when it discovers it, it executes a script with the command. In your case this could be the rtcwake command.
The docker container now creates this file, whenever the command needs to be executed.
With this, I only need to mount the directory which is checked by the systemd service to create the file and can run the docker container in normal user mode.
A little side note: To further increase security I stored the systemd configuration and the script to be executed in the read-only section of the file system.
Of course, you can use other trigger mechanisms instead of creating and deleting a file, but I like this simply approach.
I hope this helps you
Hello @n11ThoMumme
Thank you very much for the valuable suggestion.
I have applied the same approach mentioned by you ;creating and deleting of the file. creating a systemd service which checks for the specific trigger file from the main script inside the docker. when i need to execute the rtcwake from the host, i simply create a trigger txt file. The service will run the rtcwake off command to off the device when it finds the trigger txt file. since my system is solar/battery powered , so there are times when i need to run my system with only with battery when there is no sunlight for months. so i need to run my system with less power as much as possible, periodically to save power.
one concerning point is if go with create and delete the file, i have do it thousand of times since my system runs continuously with some period of about 15 minutes.
is there any effect on the device on the long run with this continuous create/delete approach? That’s why i was thinking of doing rtcwake off directly, which seems impossible inside the docker even with privileged/mount based approach. Also i think there can be some miss and also some complexity in other triggering approach besides create/deletion of file.
once again, Thank you.
is there any effect on the device on the long run with this continuous create/delete approach?
Well any sort of operation that writes to disk always slightly wears on the eMMC of the device. Over time this wear will lead to the eMMC becoming unstable/error-prone which basically marks the end of that device. But we’re talking a lot of file writes here. Typically devices create and write files all the time, this single file of yours probably won’t have any noticeable impact on the overall longevity of the eMMC.
If you’re truly concerned though. You can always just create the file in /tmp or any other volatile location in the filesystem. Locations like this aren’t actually located on the disk and are in memory so they don’t really contribute to eMMC wear.
Alternatively, you can just have have another approach to trigger this from the container. On quick search I can see others have used named pipes: How to run shell script on host from docker container? - Stack Overflow
I personally know you can use SSH in the container to access the host outside of the container via localhost. Though there’s probably more appropriate ways to do this.
Again though your current approach of creating/deleting a trigger file seems fine to me. I really can’t imagine the creation/deletion of this single file even over time will contribute to any noticeable issues.
Best Regards,
Jeremias