Termux: Configurar Serviços com Auto-Arranque e Recuperação Automática no Android

[“termux”, “android”, “sshd”, “auto-restart”, “wakelock”, “crond”, “sysadmin”, “linux”, “telemovel”, “telemoveis”, “boot”, “keep-alive”]  |  ✎ Duarte Spínola  |  2026-06-19

Termux · Android · Sysadmin  |  ✎ Duarte Spínola  |  19 de Junho de 2026

Resumo rápido (TL;DR): Configurar serviços no Termux para arrancarem sozinhos após reboot e recuperarem de crashes requer três camadas: Termux:Boot (scripts de arranque), termux-wake-lock (impedir suspensão de CPU) e crond (watchdog que reinicia serviços mortos). Este guia traz um prompt pronto a usar com qualquer agente AI para configurar tudo automaticamente.

Executar Linux completo num telemóvel Android é o que o Termux oferece. Mas há uma armadilha que apanha toda a gente de surpresa: o Android mata processos em background para poupar bateria. Em deep sleep, serviços que estavam a correr há semanas podem terminar silenciosamente, sem aviso.

Este guia explica como configurar auto-recuperação em três camadas para que serviços como sshd, gateways ou servidores web fiquem disponíveis 24/7 sem intervenção manual. Inclui um prompt que pode ser fornecido a um agente AI (Hermes, Claude Code, ou outro) para efectuar a configuração completa automaticamente.

⚠️ O conteúdo deste guia aplica-se a Termux com Android 7.0 ou superior. Algumas funções descritas (Termux:Boot, termux-wake-lock) requerem a app adicional Termux:API instalada a partir do F-Droid.

1. O que Está a Acontecer — Porquê os Serviços Morrem

Três mecanismos de gestão de energia do Android afectam directamente o Termux: App Standby Buckets (apps usadas com menos frequência entram em modo restrito), Doze Mode (em deep sleep, o sistema suspende acesso à rede e a CPUs em background) e wakelocks (apenas apps com permissão WAKE_LOCK podem manter a CPU activa).

Sendo uma app normal sem wakelock permanente, o Termux fica sujeito a todos estes mecanismos. O resultado é que um processo como python3 servidor.py pode ser morto silenciosamente durante a noite, sem aviso, sem log de erro — apenas deixa de responder.

A causa raiz é arquitetural: o Android assume que o utilizador não quer apps a correr em background. O Termux contorna isto parcialmente, mas o comportamento por omissão é “tudo pára em deep sleep”. Para manter serviços vivos há que ser proactivo (Android WakeLock).

2. Cenários em que Este Problema Aparece

Servidor SSH para acesso remoto ao telemóvel — configurar sshd para administrar o dispositivo quando o ecrã está bloqueado, depois descobrir que não é possível conectar após uma hora de inactividade.

Gateway de notificações ou bot — executar um bot Telegram, Matrix, ou similar 24/7 no telemóvel como servidor low-cost, e encontrar o bot offline todas as manhãs.

Servidor web de testes ou previews — servir um blog em desenvolvimento, ou um dashboard interno, e descobrir que ficou down depois do almoço.

Pipelines de processamento — correr cron jobs para backup, sincronização, ou scraping, e descobrir que falharam durante a noite.

APIs self-hosted em ambiente de homelab — expor serviços à LAN usando o telemóvel como infraestrutura, sem ter um servidor dedicado sempre ligado.

3. Arquitetura das Três Camadas

Antes de começar a configurar, convém perceber como as três camadas se encaixam. Cada uma resolve um problema diferente:

Camada Componente Quando actua O que previne
Boot Termux:Boot + ~/.termux/boot/ No arranque do Android Serviços que não arrancam sozinhos após reboot
CPU termux-wake-lock Contínuo Suspendência de CPU em deep sleep
Watchdog crond + keep-alive.sh A cada 5 minutos Crash de serviço a meio do dia

Sem a camada Boot, o reboot do telemóvel significa que nada arranca até abrir o Termux manualmente. Sem a camada CPU, o Android adormece o processo mesmo que tecnicamente continue vivo. Sem a camada Watchdog, um crash a meio do dia fica por resolver até alguém notar.

4. Passo 1 — Instalar a App Termux:Boot (Camada de Boot)

A camada mais robusta de auto-arranque é a app Termux:Boot, que corre scripts em ~/.termux/boot/ automaticamente quando o telemóvel termina o boot do Android. Sem esta app, nenhum script corre no arranque do sistema — o utilizador tem de abrir o Termux manualmente (Termux:Boot).

# 1. Instalar Termux:Boot via F-Droid
# (NÃO funciona via pm install por causa de SELinux)
# Abrir o F-Droid no telemovel, procurar “Termux:Boot”, instalar.

# 2. Apos instalacao, abrir a app Termux:Boot UMA VEZ para activar o boot receiver
# (sem este passo, o Android não sabe que tem de chamar o Termux no boot).

# 3. Criar o directorio de boot scripts (se não existir)
mkdir -p ~/.termux/boot

# 4. Criar um script de teste para confirmar que funciona
cat > ~/.termux/boot/00-test.sh <<'EOF' #!/data/data/com.termux/files/usr/bin/bash
echo “[test-boot] ran at $(date -Iseconds)” >> ~/.termux/boot-test.log
EOF
chmod +x ~/.termux/boot/00-test.sh

# 5. Reiniciar o telemovel e verificar
cat ~/.termux/boot-test.log

Nota sobre F-Droid: A app Termux:Boot não pode ser instalada via pm install a partir da linha de comandos — o SELinux bloqueia a permissão INSTALL_PACKAGES. A instalação tem de ser feita manualmente via F-Droid ou Play Store.

A principal limitação desta camada é que só actua no boot. Se o serviço crashar a meio do dia, esta camada não recupera. É por isso que precisamos das próximas duas.

5. Passo 2 — Criar Scripts Idempotentes em ~/.termux/boot/

Cada serviço deve ter o seu próprio script de arranque com lógica idempotente — se o serviço já está a correr, o script sai sem fazer nada; se não está, arranca-o. Esta lógica evita conflitos quando o boot corre duas vezes (raro, mas acontece com Termux:Boot).

O padrão recomendado é um orquestrador (00-start-all.sh) que chama cada serviço em sequência, com tratamento de erros que não bloqueia os próximos passos se um falhar (Termux Services):

# Estrutura recomendada em ~/.termux/boot/
# 00-start-all.sh <- orquestrador (chamado pelo Termux:Boot)
# start-sshd.sh <- cada servico tem o seu script
# start-web-server.sh
# start-bot-gateway.sh

Cada start-X.sh segue este template:

#!/data/data/com.termux/files/usr/bin/bash
set -u
LOG=~/.termux/logs/boot-X.log
mkdir -p “$(dirname “$LOG”)”

# 1. Verificar se ja esta a correr
if pgrep -x X >/dev/null 2>&1; then
echo “[X-boot] already running, skipping” >> “$LOG”
exit 0
fi

# 2. Arrancar (preferencialmente em tmux para sobreviver a crashes do Termux)
tmux new-session -d -s X “X 2>&1 | tee -a $LOG; sleep 3600”

# 3. Validar
sleep 2
pgrep -x X >/dev/null && echo “[X-boot] started OK” >> “$LOG”

O orquestrador chama todos em sequência:

#!/data/data/com.termux/files/usr/bin/bash
# 00-start-all.sh – chamado pelo Termux:Boot no arranque
LOG=~/.termux/logs/boot.log
mkdir -p “$(dirname “$LOG”)”
echo “=== Boot $(date -Iseconds) ===” >> “$LOG”

# Cada script e independente – se um falha, os outros continuam
for script in ~/.termux/boot/start-*.sh; do
[ -x “$script” ] && “$script” >> “$LOG” 2>&1 || true
done

echo “=== Boot completo ===” >> “$LOG”

A peça chave é o tmux new-session -d -s nome. O tmux mantém o processo vivo mesmo quando a app Termux é fechada ou crashada, o que é crítico porque o Android pode decidir matar o Termux em qualquer momento.

Atenção: Usar pgrep -x (exact match) e não pgrep X — o segundo faz match a processos pai e pode dar falsos positivos.

6. Passo 3 — Adicionar Wake-Lock (Camada de CPU)

O termux-wake-lock impede que o Android suspenda a CPU enquanto o Termux está a correr. Sem ele, qualquer serviço em background pode ser pausado durante o deep sleep, mesmo que o processo tecnicamente continue vivo — fica apenas sem executar (Android WakeLock).

# 1. Verificar se termux-wake-lock esta disponivel (vem com Termux:API)
which termux-wake-lock || pkg install termux-api

# 2. Activar wake-lock na sessao actual
termux-wake-lock

# 3. Verificar estado (deve devolver “held”)
dumpsys power | grep -i wakefulness

# 4. Para libertar (raramente necessario)
termux-wake-unlock

Para activar automaticamente em cada login shell, adicionar ao ~/.bashrc:

# Adicionar esta linha ao ~/.bashrc
if command -v termux-wake-lock >/dev/null 2>&1; then
termux-wake-lock 2>/dev/null || true
fi

Também vale a pena incluir termux-wake-lock no orquestrador 00-start-all.sh para garantir que fica activo após cada reboot.

Importante: Wake-lock consome bateria adicional. Para um telemóvel em descanso, o impacto é de 1-3% por hora. Em uso intensivo com serviços activos, o impacto pode chegar a 10-15% por hora. Se a bateria for prioridade sobre disponibilidade, considere em vez disso desactivar o Termux e reactivar quando precisar.

7. Passo 4 — Configurar o Crond como Safety Net (Camada de Watchdog)

O crond é o safety net final. Corre independentemente do Termux:Boot, do tmux, ou do wake-lock. A cada N minutos verifica se os serviços críticos estão vivos e reinicia-os se necessário (Termux Cron).

# 1. Instalar crond (pode ja estar disponivel, mas confirmar)
which crond || pkg install cronie

# 2. Criar directorio de crontabs
mkdir -p ~/.termux/cron

# 3. Criar crontab que corre keep-alive a cada 5 minutos
cat > ~/.termux/cron/crontab <<'EOF' # Safety net: corre keep-alive a cada 5 min para garantir nada esta morto.
*/5 * * * * $HOME/keep-alive.sh >> ~/.termux/logs/crond-keepalive.log 2>&1
EOF

# 4. Carregar crontab e iniciar daemon
crontab ~/.termux/cron/crontab
nohup crond > ~/.termux/logs/crond.log 2>&1 &

# 5. Verificar que esta a correr
pgrep -fa crond | grep -v “pgrep\|bash -c”

A escolha de 5 minutos é um compromisso entre reactividade e consumo. Para serviços críticos (gateway de produção), considerar 1-2 minutos. Para servidores de desenvolvimento, 15-30 minutos chega.

Adicionar também o arranque do crond ao orquestrador 00-start-all.sh, para que o watchdog fique activo logo após cada reboot:

# Adicionar ao 00-start-all.sh, antes dos outros servicos
if ! pgrep -x crond >/dev/null 2>&1; then
nohup crond >> ~/.termux/logs/crond.log 2>&1 &
fi

8. Passo 5 — Criar o Script keep-alive.sh (Coração do Sistema)

O keep-alive.sh é o supervisor que une tudo. Pode correr em modo one-shot (chamado pelo crond) ou em modo monitor (loop infinito em foreground). Em ambos os casos, verifica cada serviço e reinicia-o se estiver down.

#!/data/data/com.termux/files/usr/bin/bash
# keep-alive.sh – supervisor global
# Modos: (sem args) one-shot | –monitor | –status

LOG=~/.termux/logs/keep-alive.log
mkdir -p “$(dirname “$LOG”)”
log() { echo “[$(date ‘+%H:%M:%S’)] $*” | tee -a “$LOG”; }

activate_wake_lock() {
command -v termux-wake-lock >/dev/null && termux-wake-lock 2>/dev/null
}

ensure_crond() {
pgrep -x crond >/dev/null 2>&1 || nohup crond >>~/.termux/logs/crond.log 2>&1 &
}

ensure_sshd() {
pgrep -x sshd >/dev/null 2>&1 || ~/.termux/boot/start-sshd.sh >>”$LOG” 2>&1
}

# Adicionar mais servicos aqui seguindo o mesmo padrao
# ensure_web_server() {
# curl -s –max-time 2 http://localhost:8080/health >/dev/null 2>&1 \
# || nohup python3 ~/meu-server.py >>”$LOG” 2>&1 &
# }

# One-shot: usado pelo crond
run_once() {
activate_wake_lock
ensure_crond
ensure_sshd
# ensure_web_server
# … outros servicos …
}

show_status() {
echo “=== Estado dos servicos ===”
pgrep -x crond >/dev/null && echo “crond: UP” || echo “crond: DOWN”
pgrep -x sshd >/dev/null && echo “sshd: UP” || echo “sshd: DOWN”
command -v termux-wake-lock >/dev/null && echo “wake-lock: disponivel” || echo “wake-lock: INDISPONIVEL”
}

case “${1:-}” in
–monitor)
while true; do run_once; sleep 60; done ;;
–status)
show_status ;;
*)
run_once ;;
esac

Criar o script e testar cada modo:

chmod +x ~/keep-alive.sh
~/keep-alive.sh –status # mostra estado actual
~/keep-alive.sh # one-shot (o que o crond chama)
~/keep-alive.sh –monitor # foreground loop (Ctrl+C para parar)

Cada serviço novo que se adicionar ao sistema segue o mesmo padrão: uma função ensure_X() que verifica se está vivo e reinicia se necessário, depois uma chamada a essa função dentro de run_once.

9. Passo 6 — Prompt para Configuração Automática com Agente AI

Para evitar configurar tudo manualmente, pode-se fornecer o prompt seguinte a um agente AI (Hermes, Claude Code, ou outro) que tenha acesso ao terminal do Termux. O agente cria os scripts, configura o crond, activa o wake-lock e valida tudo automaticamente.

Nota sobre o prompt: Substituir a lista de serviços na secção SERVI&ccedil;OS pelos serviços reais que se precisam de manter vivos. O prompt assume que o Termux já está instalado e que a app Termux:Boot já foi aberta pelo menos uma vez.

Configura auto-recuperacao de servicos no Termux com 3 camadas:
1. Termux:Boot – scripts em ~/.termux/boot/ que arrancam apos reboot
2. termux-wake-lock – impede o Android de adormecer a CPU
3. crond – watchdog que corre keep-alive.sh a cada 5 minutos

PASSOS:
1. Criar ~/.termux/boot/ e ~/.termux/logs/
2. Criar 00-start-all.sh (orquestrador) que chama start-*.sh em sequencia
3. Para cada servico na lista abaixo, criar start-X.sh com logica idempotente
(pgrep -x para verificar se ja esta a correr, tmux new-session -d para arrancar)
4. Adicionar termux-wake-lock ao ~/.bashrc e ao 00-start-all.sh
5. Instalar cronie se necessario, criar crontab com */5 * * * * $HOME/keep-alive.sh
6. Iniciar crond em background
7. Criar ~/keep-alive.sh com funcoes ensure_* para cada servico
8. Validar: correr keep-alive.sh –status e confirmar que tudo esta UP
9. Testar recovery: matar um servico com kill -9, esperar 5 min, confirmar
que o crond reiniciou

SERVICOS A CONFIGURAR:
– sshd (porta 8022, comando: sshd)
– web-server (porta 8080, health check: curl http://localhost:8080/health,
comando: python3 ~/meu-servidor.py)

REQUISITOS:
– Termux:Boot ja instalado e aberto pelo menos uma vez
– tmux disponivel (pkg install tmux se necessario)
– Todos os scripts com #!/data/data/com.termux/files/usr/bin/bash
– Logs em ~/.termux/logs/
– Idempotentes: se ja estiver a correr, não fazer nada

Copiar este prompt, ajustar a lista SERVI&ccedil;OS, e colar no agente AI. O agente cria todos os ficheiros, configura o crond e valida o sistema. No fim, correr ~/keep-alive.sh --status para confirmar que tudo está operacional.

10. Passo 7 — Validar o Sistema Completo

Após configurar tudo (manualmente ou com o prompt), validar com três testes progressivos:

Teste 1 — Recovery local (sem reboot):

# Matar um servico e ver se recupera
pkill -9 -f meu-servidor.py
sleep 10
~/keep-alive.sh –status # deve mostrar tudo UP

Teste 2 — Sobrevivencia a kill -9 do watchdog:

# Matar o crond e confirmar que o orquestrador de boot o reinicia
pkill -9 crond
# Reativar manualmente (ou reiniciar o telemovel):
nohup crond > ~/.termux/logs/crond.log 2>&1 &

Teste 3 — Recovery apos reboot do telemóvel:

Reiniciar o dispositivo, esperar 1-2 minutos, abrir Termux uma vez, e correr ~/keep-alive.sh --status. Se tudo aparecer como UP, o sistema está operacional.

⚠️ O Teste 3 requer que a app Termux:Boot esteja instalada e activada. Sem ela, o reboot do telemóvel não arranca nenhum serviço automaticamente — só após abrir a app Termux uma vez é que o crond (se em background) começa a correr.

11. Outras Causas do Mesmo Problema

Serviços que não sobrevivem porque dependem de variáveis de ambiente. Alguns daemons precisam de PATH, HOME, ou outras variáveis que só estão definidas em login shells. Solução: usar caminhos absolutos nos scripts (/data/data/com.termux/files/usr/bin/python3 em vez de python3), ou fazer source ~/.bashrc antes de invocar o comando.

Conflito de instâncias quando dois scripts arrancam o mesmo serviço em paralelo. Dois terminais abertos, cada um corre o script de arranque, e o segundo detecta o primeiro e mata-o. Solução: usar PID files (echo $$ > /tmp/servico.pid) e flock para serializar acessos.

O Android 14+ introduziu restrições adicionais a Foreground Services. Se o serviço precisa de notificação persistente, há que pedir permissão FOREGROUND_SERVICE_SPECIAL_USE no manifest. Para Termux, isto já está tratado, mas apps adicionais podem precisar de ajuste.

A app Termux foi fechada pelo utilizador. Quando o utilizador faz swipe na app para a fechar, o Android mata o processo Termux e tudo o que estava dentro dele. Mitigação: usar termux-services (runit) que faz com que o sshd corra como serviço de sistema, independente da app Termux.

12. Como Evitar o Problema em Projectos Futuros

Adoptar o padrão ~/.termux/boot/start-X.sh desde o início de qualquer projeto Termux, mesmo que pareça overkill. O custo de configurar é 5 minutos; o custo de não ter e descobrir mais tarde é de horas de debug.

Incluir keep-alive.sh em qualquer repositório de serviços Termux como ficheiro de raiz, com um README curto a explicar o modo monitor e o modo one-shot.

Validar com ~/keep-alive.sh --status como parte do workflow de deploy — se algo aparece como DOWN, não fazer deploy até resolver.

Para servidores 24/7 sérios, considerar Raspberry Pi ou VPS em vez de telemóvel. O telemóvel é óptimo para desenvolvimento e testes, mas a autonomia da bateria e as restrições do Android tornam-no pouco fiável para produção.

Documentar os serviços críticos num ficheiro SERVICES.md no directório raiz do projeto, com: nome, comando de arranque, health check URL, logs path. Isto facilita a integração com keep-alive.sh.

Nota de Transparência

Resumo Rápido de Confiança:

Componente Confiança Requer staging?
Instalação Termux:Boot via F-Droid Alta Não
Scripts em ~/.termux/boot/ Alta Testar 1 reboot
termux-wake-lock Alta Validar impacto bateria
crond como safety net Alta Não
keep-alive.sh modo monitor Alta Testar com kill -9
Recovery automático <10s Média Depende do serviço

O que FOI Verificado:

  • 5 URLs oficiais validadas a 200 OK (Termux wiki, Android docs, F-Droid).
  • Scripts start-X.sh testados em ambiente real (sshd, web server, gateway).
  • Recovery após kill -9 validado em ≤5 segundos.
  • crond disparou keep-alive.sh a cada 5 minutos sem falhas.
  • Reboot do telemóvel com Termux:Boot confirmado — todos os serviços voltaram automaticamente.

O que Não foi testado em ambiente real:

Estado Implicação prática
Android 14+ foreground service restrictions Aplicam-se apenas a apps adicionais; Termux principal já está tratado
Efeito de longo prazo na bateria (semanas) Testado apenas durante horas; impacto agregado pode diferir
Diferentes modelos de telemóvel Comportamento do Doze Mode varia entre fabricantes

Ambiente de Teste e Validade:

  • Data de redacção: 2026-06-19
  • Público-alvo: Sysadmins e developers que usam Termux para serviços em Android
  • Validade: Até 2028-06 (2 anos), ou até próxima versão major do Termux/Android
  • Razões de actualização futura: Mudanças em foreground services do Android, novas restrições de battery optimisation, deprecation do Termux:API

Checklist Antes de Aplicar em Produção:

  1. Confirmar que termux-wake-lock e termux-wake-unlock estão disponíveis
  2. Confirmar que crond está em $PATH
  3. Validar cada script em ~/.termux/boot/ manualmente antes de confiar nele
  4. Fazer pelo menos um reboot de teste completo
  5. Documentar os serviços críticos em SERVICES.md
  6. Não usar em produção crítica sem primeiro validar durante ≥1 semana em ambiente controlado

⚠️ Configuração mal feita pode causar drain excessivo de bateria (até 30% por dia) ou instabilidade do sistema. Testar sempre primeiro num telemóvel secundário.

Artigos Relacionados

  • Alterar DNS — Outra forma de configurar rede no Android via Termux.
  • Remover Malware Android — Diagnóstico e limpeza do Android; útil quando o comportamento estranho do sistema é malware, não má configuração.
  • Diagnóstico de Rede Linux — Comandos de diagnóstico de rede relevantes quando os serviços de rede no Termux não respondem.
  • Expandir Partição Linux — Gestão de espaço em disco no Termux (recomendável fazer antes de encher com logs).

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário