I’m doing some testing with Android TV boxes/tablets running Termux, SSH YaCy and Nextcloud.
During setup I’ve sometimes been rebooting the device simply by removing power and reconnecting it.
How safe is this to do repeatedly?
I’m mainly concerned about the internal eMMC storage and filesystem. One of my devices has a Samsung 128 GB eMMC manufactured in 2017, and its health information currently looks very good:
life_time : 0x01 0x01
pre_eol_info : 0x01
So the eMMC itself reports only 0–10% of its rated lifetime used and a normal pre-EOL condition.
My concern is more about cutting power while Android, Termux or an application such as YaCy or Nextcloud is actively writing data.
Is there a significant risk of file system/database corruption from repeated hard power cycles, even if the eMMC itself is healthy?
I’m interested in other people’s experience running small Android devices like this 24/7.
Why the hell you do not use Termux System & Process Management Commands to Stop a process by PID or by name instead of risking data corruption by removing power to reboot the device ???
It will eventually fail if it’s constantly written to, but that doesn’t really relate to the rest of your question.
That’s never a good idea, on any system, but it has nothing specifically to do with the eMMC. The issue is data consistency: whatever was being written at the time may end up incomplete or corrupted. With Nextcloud, you also have the database to consider.
With Termux, the kill command could be part of the solution if we’re talking about actual processes. However, if you simply kill the web server while a large file is being uploaded, I certainly wouldn’t rely on it waiting ten minutes for the upload to finish, especially with chunked uploads or PHP-FPM in the mix.
In any case, I wouldn’t use devices without proper process management nor would I use eMMC for any production-critical server applications. For a proof of concept or a small Nextcloud instance for sharing a few files, though, it should be fine. With regular backups, you could probably use it for personal files too.
But even in the current RAM/storage crisis, one should still be able to afford a mini PC with a proper SSD of at least 128 GB.
Terminating processes normally using -SIGTERM (15) is always preferable, as this allows the programme the opportunity to exit ‘gracefully’. Only if a -SIGTERM (15) is not accepted should you instruct the kernel, using -SIGKILL (9), to debug (dump) the process and force it to terminate.
Ultimately, this means that a process terminated with -SIGTERM (15) at least terminates the write operation in the file system properly, even if the entire file has not yet been written to the storage medium. It’s different if you simply pull the plug out of the socket
eMMC typically has lower specified write endurance than SSDs. This is influenced by factors such as NAND type, over-provisioning, and controller/firmware design. However, this is fundamentally a separate issue from how the device behaves during a sudden power loss.
Enterprise SSDs with proper Power Loss Protection (PLP) have an advantage in this regard. The stored energy allows the SSD controller to safely persist critical in-flight data and internal metadata when power is suddenly removed. However, the primary goal is to preserve the consistency and integrity of the SSD and its mapping/metadata structures, rather than to guarantee that every application-level write or file operation is completed. PLP is not a magic solution that prevents all data loss.
So, a proper graceful shutdown of all services is always preferable, regardless of the storage media. It gives the OS and applications the opportunity to flush pending writes and shut down cleanly. This allows databases, the filesystem, and other applications to properly commit or roll back pending operations and leave everything in a consistent state.
Pure stock Android does not feature a universal, built-in menu to make apps open on boot. However, custom manufacturer skins (like MIUI or Samsung One UI) often include auto-launch toggles, and you can force apps to start using third-party tools or automation apps like MacroDroid.
With that knowledge you need to google or ask an AI how to enable or disable autostart of Termux on your specific TV device.
The issue: I found when running Ubuntu under Termux/AnLinux proot is that Ubuntu would not exit normally after starting Apache or MariaDB.
For example, after:
service mariadb start
service apache2 start
typing:
exit
would leave the proot Ubuntu session hanging.
Testing the services individually showed that either Apache or MariaDB running was enough to prevent the Ubuntu/proot environment from exiting cleanly.
Stopping the services first fixes the problem:
service apache2 stop
service mariadb stop
exit
After both services have stopped, Ubuntu exits normally and returns to Termux.
For convenience, I added an alias to Ubuntu’s /root/.bashrc:
alias logoutubuntu='service apache2 stop; service mariadb stop; exit'
Reload it:
source ~/.bashrc
Now I can simply use:
logoutubuntu
This stops Apache and MariaDB before exiting Ubuntu.
This appears to be a proot process-lifecycle behaviour rather than a problem with Apache or MariaDB themselves. Long-running service processes keep the proot environment alive, so stopping them before exiting provides a simple workaround.
