Интеграция Termux с системным init‑system Android: создание пользовательских сервисов, автозапуск и управление через systemd‑ish‑скрипты

Termux позволяет превратить смартфон или планшет Android в гибкую среду для автоматизации: запуск фоновых задач, периодические задания, сетевые клиенты, обслуживание локальных сервисов и сценарии администрирования. Однако “классический” init-system Android не рассчитан на непосредственное подключение сторонних пользователей и приложений как на обычной Linux-системе. Поэтому на практике применяется подход systemd-ish: мы создаём собственный механизм пользовательских сервисов в рамках Termux и надежно запускаем их через Android‑события (например, при входе пользователя или запуске приложения), сохраняя контроль, наблюдаемость и управляемость.

В этой статье — практическая архитектура интеграции Termux с “системным” подходом: пользовательские сервисы, автозапуск, логи, статусы и команды управления. Приведённые методы ориентированы на легальные и безопасные сценарии использования в рамках возможностей Android.

Концепция: что значит “systemd-ish” на Android

На Android нет systemd как части ОС, но есть механизмы автозапуска приложений и выполнение команд в окружении приложения. Поэтому мы реализуем модель, похожую на systemd:

• Unit — описание сервиса (bash-скрипт, команда, зависимости на сеть/хранилище).
• Service — исполнение команды с PID/статусом, логированием и перезапусками при необходимости.
• Start/Stop/Restart — единые команды для управления.
• Autostart — запуск “менеджера” сервисов при подходящем событии Android.

Ключевая идея: Termux остаётся пользователем, а управление строится вокруг ваших скриптов и логики менеджера.

Подготовка окружения в Termux

Перед тем как писать “сервисы”, приведите базу Termux к стабильному состоянию.

1) Обновите пакеты:

pkg update -y && pkg upgrade -y

2) Установите минимально полезные утилиты (если ещё нет):

pkg install -y coreutils procps grep sed awk util-linux inotify-tools

3) Проверьте, что у Termux есть доступ к необходимым ресурсам (например, сети). В зависимости от вашего Android и настроек разрешений, доступ к сети может требовать дополнительных действий в настройках приложения.

Структура проекта сервисов

Для поддерживаемости заведём каталог, где будут храниться ваши “unit-файлы” (по сути: конфигурации) и скрипты.

mkdir -p $HOME/.local/service-manager/{units,bin,run,log}

Предлагаемая схема:

• $HOME/.local/service-manager/units/ — описание сервисов (shell-конфиги)
• $HOME/.local/service-manager/bin/ — исполняемые шаблонные скрипты
• $HOME/.local/service-manager/run/ — PID-файлы
• $HOME/.local/service-manager/log/ — логи

Менеджер сервисов: единая точка управления

Сделаем скрипт-менеджер, который понимает команды start, stop, status, restart для ваших сервисов. Ниже приведён простой, но практичный “systemd-ish” каркас.

Создайте файл $HOME/.local/service-manager/bin/svc:

cat > $HOME/.local/service-manager/bin/svc <<'EOF'
#!/data/data/com.termux/files/usr/bin/env bash
set -euo pipefail

BASE="$HOME/.local/service-manager"
UNITS="$BASE/units"
RUN="$BASE/run"
LOG="$BASE/log"

cmd="${1:-}"
unit="${2:-}"

if [[ -z "$cmd" || -z "$unit" ]]; then
  echo "Usage: svc <start|stop|restart|status> <unit-name>"
  exit 2
fi

unit_file="$UNITS/$unit"
if [[ ! -f "$unit_file" ]]; then
  echo "Unit not found: $unit_file"
  exit 1
fi

# shellcheck disable=SC1090
source "$unit_file"

# Expected variables from unit:
# NAME, DESCRIPTION, CMD, USER_MODE (optional), AUTORESTART (0/1), WORKDIR (optional), RESTART_DELAY (seconds)

pid_file="$RUN/$NAME.pid"
log_file="$LOG/$NAME.log"

start() {
  if [[ -f "$pid_file" ]] && kill -0 "$(cat "$pid_file")" 2>/dev/null; then
    echo "$NAME is already running (pid=$(cat "$pid_file"))."
    return 0
  fi

  mkdir -p "$LOG" "$RUN"

  workdir="${WORKDIR:-$HOME}"
  nohup bash -lc "cd "$workdir"; exec $CMD" 
    >>"$log_file" 2>&1 &

  pid=$!
  echo "$pid" > "$pid_file"
  echo "Started $NAME (pid=$pid)."
}

stop() {
  if [[ ! -f "$pid_file" ]]; then
    echo "$NAME is not running."
    return 0
  fi
  pid="$(cat "$pid_file")"
  if kill -0 "$pid" 2>/dev/null; then
    kill "$pid" 2>/dev/null || true
    # мягкая остановка
    for i in {1..10}; do
      if ! kill -0 "$pid" 2>/dev/null; then break; fi
      sleep 0.2
    done
    # жёсткая остановка при необходимости
    if kill -0 "$pid" 2>/dev/null; then
      kill -9 "$pid" 2>/dev/null || true
    fi
  fi
  rm -f "$pid_file"
  echo "Stopped $NAME."
}

status() {
  if [[ -f "$pid_file" ]]; then
    pid="$(cat "$pid_file")"
    if kill -0 "$pid" 2>/dev/null; then
      echo "$NAME: active (pid=$pid)"
      exit 0
    fi
  fi
  echo "$NAME: inactive"
  exit 3
}

restart() {
  stop || true
  start
}

case "$cmd" in
  start) start ;;
  stop) stop ;;
  status) status ;;
  restart)
    restart ;;
  )
    echo "Unknown command: $cmd"
    exit 2
    ;;
esac
EOF

Сделайте менеджер исполняемым и удобно доступным:

chmod +x $HOME/.local/service-manager/bin/svc
ln -sf $HOME/.local/service-manager/bin/svc $HOME/bin/svc
hash -r || true

Единица обслуживания (unit): пример сервиса

Создадим пример сервиса, который запускает локальный HTTP-сервис или команду, которую вы выберете сами. Важно: в Android “фоновые сервисы” зависят от ограничений энергосбережения, а значит перезапуски и стабильность нужно тестировать на вашем устройстве.

Пример: echo-сервер логов не нужен; лучше продемонстрировать запуск реального процесса. Допустим, вы хотите запускать периодический “worker” — скрипт, который раз в минуту пишет в лог.

Создайте unit-файл $HOME/.local/service-manager/units/worker-demo:

cat > $HOME/.local/service-manager/units/worker-demo <<'EOF'
NAME="worker-demo"
DESCRIPTION="Demo periodic worker"
WORKDIR="$HOME"

# В Termux CMD — это командная строка, которая будет передана в bash -lc.
# Используйте безопасные, предсказуемые команды.
CMD='while true; do date; echo "worker-demo: tick"; sleep 60; done'

AUTORESTART=0
RESTART_DELAY=3
EOF

Запуск:

svc start worker-demo

Проверка статуса:

svc status worker-demo

Просмотр логов:

tail -n 50 $HOME/.local/service-manager/log/worker-demo.log

Остановка:

svc stop worker-demo

Перезапуск:

svc restart worker-demo

Автозапуск: как запускать менеджер после старта Android

Автозапуск на Android не является “унифицированным” как на Linux: ОС и производитель могут ограничивать фоновые запуски. Поэтому практичный подход — запуск через механизм, который надёжно запускает Termux “в нужный момент”, и дальше уже сам менеджер поднимает ваши сервисы.

Подход 1 (часто самый простой): Termux:Boot (приложение-плагин) или аналогичный способ автозапуска в рамках Termux-сообщества. Он позволяет выполнить команду при событии загрузки/старта.

Какой бы инструмент вы ни выбрали, логика одна: вы запускаете service-manager скриптом, и он стартует нужные unit-ы.

Сделаем “boot entrypoint” в Termux: список сервисов и их запуск.

Создайте файл $HOME/.local/service-manager/bin/autostart:

cat > $HOME/.local/service-manager/bin/autostart <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

BASE="$HOME/.local/service-manager"
LIST="$BASE/units-to-start"

mkdir -p "$BASE/run" "$BASE/log"

# Если списка нет — ничего не делаем.
if [[ ! -f "$LIST" ]]; then
  exit 0
fi

while IFS= read -r unit; do
  # пропускаем пустые строки и комментарии
  [[ -z "$unit" ]] && continue
  [[ "$unit" =~ ^[[:space:]]# ]] && continue
  "$HOME/.local/service-manager/bin/svc" start "$unit" || true
done < "$LIST"
EOF

Сделайте исполняемым:

chmod +x $HOME/.local/service-manager/bin/autostart

Теперь определите, какие сервисы стартовать:

cat > $HOME/.local/service-manager/units-to-start <<'EOF'
# Автозапуск сервисов Termux (systemd-ish)
worker-demo
EOF

Далее в вашем инструменте автозапуска (например, через событие boot) задайте команду:

$HOME/.local/service-manager/bin/autostart

Важное замечание по сетевым сервисам: если ваш сервис зависит от сети, добавляйте проверку доступности (например, ожидание DNS или маршрута). Иначе сервис стартует, но сразу завершится.

Зависимости и ожидание сети (пример в unit)

Мягкий способ: обернуть команду в unit так, чтобы она ждала сетевую готовность.

Например, в CMD можно добавить ожидание подключения:

CMD='
for i in {1..30}; do
  if command -v curl >/dev/null 2>&1; then
    curl -fsS https://example.com >/dev/null 2>&1 && break
  else
    # fallback: простая проверка через ping, если есть
    ping -c 1 -W 1 1.1.1.1 >/dev/null 2>&1 && break
  fi
  sleep 2
done
while true; do
  echo "network-ready worker: $(date)"
  sleep 60
done
'

Этот подход подходит для сервисов, которым критична доступность сети (для любых легитимных задач: уведомления, локальные вебхуки, работа с публичными API и т. п.).

Логи, ротация и диагностика

Для “systemd-ish” управления логирование — обязательная часть. Мы уже используем nohup и пишем в log/<name>.log. Улучшите поведение ротацией, чтобы лог не рос бесконечно.

Простейший вариант: запускать отдельный лог-роллинг таймером (например, отдельным unit или cron в Termux — если вы его используете).

Пример сценария ротации создайте:

cat > $HOME/.local/service-manager/bin/log-rotate <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
BASE="$HOME/.local/service-manager"
LOG="$BASE/log"

# Обрезка/ротация: оставляем до 5 файлов по 5MB (упрощённо).
max_bytes=$((510241024))
for f in "$LOG"/*.log; do
  [[ -e "$f" ]] || continue
  size=$(stat -c%s "$f" 2>/dev/null || echo 0)
  if [[ "$size" -gt "$max_bytes" ]]; then
    name="$(basename "$f")"
    # Сдвиг: .4 -> .5 (удалится), .3 -> .4 ...
    for i in 4 3 2 1 0; do
      if [[ -f "$LOG/$name.$i" ]]; then
        mv -f "$LOG/$name.$i" "$LOG/$name.$((i+1))" || true
      fi
    done
    mv -f "$f" "$f.0"
    : > "$f"
  fi
done
EOF
chmod +x $HOME/.local/service-manager/bin/log-rotate

А unit “log-rotate” может раз в N минут вызывать этот скрипт.

Перезапуски (AUTORESTART) и управляемость

В простом варианте менеджер стартует процесс и сохраняет PID. Если вам требуется автоматический restart при падении, добавьте в шаблон service-обёртку (или реализуйте watchdog unit).

Паттерн: “watchdog” запускает нужный сервис как дочерний процесс и при завершении поднимает заново. Это полностью реализуемо в Termux.

Однако практичнее начать с управляемых restart-команд и добавить AUTORESTART только для критичных задач — так меньше “скачков” при ошибках командной строки.

Подход к автозапуску через локальную сеть (опционально)

Если ваши сервисы должны создавать локальную сеть или быть доступны в локальном окружении, вы можете использовать VPN/туннели только для формирования локальной сети и удобства доступа. Важно не использовать такие схемы для обхода блокировок. Механика “systemd-ish” остаётся прежней: сервис стартует после готовности сети и после того, как интерфейс/маршрут активен.

Рекомендации по безопасности

• Храните unit-конфиги в каталоге своего пользователя Termux и ограничьте права файлов.
• Не используйте команды с неэкранированными пользовательскими вводами в CMD.
• Разделяйте сервисы по принципу минимальных прав (если сервис требует файлы — выдавайте доступ точечно, в пределах возможностей Termux).
• Проверяйте лог-файлы: в них часто попадают токены и секреты — избегайте печати секретов.

Проверочный чек-лист

• Сервис стартует вручную: svc start <unit>
• Есть наблюдаемость: логи пишутся в log/<name>.log
• Остановка работает: svc stop <unit>
• Автозапуск поднимает нужные единицы: autostart вызывается при boot
• Сетевые зависимости учтены: сервис не “умирает” из-за раннего старта без сети

Заключение

Интеграция Termux с “системным” init‑подходом на Android реализуется через user-space менеджер и systemd-ish скрипты: вы формируете единицы (unit), централизованно управляете сервисами (start/stop/status/restart) и обеспечиваете автозапуск через механизм событий Android с отдельным entrypoint. Такой подход даёт предсказуемость, наблюдаемость и удобное управление, не требуя от пользователя “ломать” систему.

Если хотите, чтобы мы помогли настроить автозапуск под вашу модель устройства, оптимизировали логи, добавили watchdog/AUTORESTART и сделали аккуратные зависимости от сети — обращайтесь в РыбинскЛАБ.