Интеграция Termux с systemd‑подобными сервисами: termux-boot и пользовательские службы

Termux — удобная среда для запуска скриптов и приложений прямо на Android. Однако типичный вызов вручную командой в интерактивной сессии неудобен, когда задача должна подниматься после перезагрузки, работать в фоне и управляться как «сервис». В этой статье разберём интеграцию Termux с systemd‑подобной моделью сервисов: с использованием модуля termux-boot для автозапуска и созданием пользовательских служб (юнитов) для фоновых задач.

Материал ориентирован на легальные сценарии автоматизации: запуск собственных скриптов, фоновых мониторингов, периодических задач и сервисов внутри вашего Termux-окружения.

Термины и компоненты

• termux-boot — модуль, который позволяет выполнять команды Termux при старте/перезапуске устройства (точнее: при событиях загрузки Android).
• systemd‑подобные службы — модель управления процессами через юниты (по смыслу как в systemd: единицы выполнения с параметрами запуска, перезапуска, зависимостей и т.п.).
• Юнит (service) — конфигурация службы с командой запуска и опциями (аналог systemd unit-файла).
• Пользовательские службы — запуск в контексте пользователя (в нашем случае — пользователь Termux и его окружение).

Предварительные требования

Перед началом проверьте:

• Termux установлен и вы имеете доступ к файловой системе.
• Вы понимаете, где у Termux расположен ваш домашний каталог: по умолчанию это ~.
• Скрипт/команда вашей фоновой задачи запускаются вручную (то есть сначала проверьте интерактивно).
• Учитывайте ограничения Android по фоновым задачам: при агрессивном энергосбережении поведение может отличаться. Для стабильности важно корректно настроить запуск и логирование.

Шаг 1. Установка termux-boot и базовых пакетов

Обновите пакеты и установите termux-boot. Выполните:

pkg update
pkg upgrade -y
pkg install termux-boot

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

Шаг 2. Подготовка точки автозапуска

Логика обычно такая: при загрузке устройства termux-boot запускает скрипт, который в свою очередь стартует ваши systemd‑подобные службы (или запускает менеджер служб, если он у вас настроен).

Сконфигурируйте команду автозапуска. Как правило, для termux-boot используется механизм, где вы определяете, какие команды запускать на событиях загрузки. Обычно это делается через файл автозапуска в каталоге Termux.

Начните с проверки, где именно termux-boot ожидает конфигурацию в вашей сборке. Самый практичный подход — найти примеры файлов конфигурации в системе Termux и проверить документацию пакета:

dpkg -L termux-boot 2>/dev/null | head

Далее откройте соответствующий конфиг/скрипт автозагрузки (путь зависит от конкретной реализации пакета). Если у вас есть типовой шаблон, создайте пользовательский скрипт в ~/scripts.

mkdir -p ~/scripts
nano ~/scripts/start-services.sh

Вставьте заготовку, где вы сможете запускать свои службы:

#!/data/data/com.termux/files/usr/bin/sh
# Пример: точка входа для автозапуска ваших фоновых задач

# Здесь вызываются команды старта (пользовательские сервисы/юниты).
# Добавьте свои команды ниже.

# Пример:
# systemctl --user start my-service.service

echo "Termux autostart: starting services..." >> $HOME/service-autostart.log

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

chmod +x ~/scripts/start-services.sh

Теперь вам нужно «привязать» этот скрипт к termux-boot. Для этого обновите конфигурацию termux-boot на событие boot, чтобы она запускала ваш скрипт. В зависимости от версии и реализации пакета путь может отличаться, поэтому используйте поиск по названию файлов в Termux.

Попробуйте найти упоминания «boot» или «start-services» в установленном пакете:

grep -R "boot" -n /data/data/com.termux/files/home 2>/dev/null | head
# а также:
grep -R "termux-boot" -n /data/data/com.termux/files/usr/share 2>/dev/null | head

После того как вы определите точный файл/механизм, настройте запуск вашего скрипта. Например, если конфигурация ожидает строку команды для запуска при загрузке, укажите:

~/scripts/start-services.sh

Сохраните изменения и проверьте, что скрипт действительно выполняется после перезапуска Termux/устройства.

Шаг 3. Создание systemd‑подобной пользовательской службы

Далее рассмотрим логику создания пользовательского юнита для вашей задачи. В типичном подходе вам потребуется:

• Определить юнит-файл в каталоге пользовательских служб.
• Указать команду запуска.
• Задать опции перезапуска и поведения.
• Добавить зависимости/ожидания (например, сеть или файловая система).
• Настроить логирование (в ideal-case — в отдельные файлы или через встроенный лог механизм).

Каталог для пользовательских unit-файлов обычно выглядит как:

• ~/.config/systemd/user/ (классический подход)

Создайте каталог:

mkdir -p ~/.config/systemd/user

Теперь создадим пример службы. Допустим, у нас есть скрипт, который делает периодический лог или мониторинг.

Шаг 1: подготовьте команду/скрипт задачи. Например, создадим скрипт ~/scripts/hello-loop.sh:

nano ~/scripts/hello-loop.sh

Содержание (пример — пишем метки времени):

#!/data/data/com.termux/files/usr/bin/sh
while true; do
  date >> "$HOME/hello-loop.log"
  sleep 60
done

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

chmod +x ~/scripts/hello-loop.sh

Шаг 2: создайте unit-файл, например hello-loop.service:

nano ~/.config/systemd/user/hello-loop.service

Пример содержимого:

[Unit]
Description=Termux user service: hello loop
After=network.target

[Service]
Type=simple
ExecStart=%h/scripts/hello-loop.sh
Restart=always
RestartSec=5

# Привычные для desktop/systemd опции тут могут отличаться по реализации.
# Мы используем минимальные безопасные параметры.

[Install]
WantedBy=default.target

Сохраните файл. Чтобы systemd‑подобный менеджер увидел изменения, выполните перезагрузку конфигурации и проверьте статус. В зависимости от того, каким именно менеджером вы пользуетесь (и есть ли он в Termux), команды могут отличаться. Попробуйте типичный набор:

systemctl --user daemon-reload
systemctl --user enable hello-loop.service
systemctl --user start hello-loop.service

Если systemctl в вашей среде отсутствует, значит у вас не установлен менеджер systemd‑подобных сервисов или используется другой механизм. Тогда уместно обсудить ваш конкретный стек: какая реализация «user service» вам доступна в Termux, и как она запускается.

Шаг 4. Подключение службы к автозапуску через termux-boot

Теперь свяжем автозапуск. В точке входа, которую вы создали на шаге 2 (~/scripts/start-services.sh), добавьте команды старта вашей службы:

#!/data/data/com.termux/files/usr/bin/sh
# Автозапуск пользовательских служб после загрузки Android

LOGFILE="$HOME/service-autostart.log"
echo "Termux autostart: starting services..." >> "$LOGFILE"

# Подключите именно вашу команду/реализацию.
# Для примера предполагаем наличие systemctl --user:

systemctl --user daemon-reload >> "$LOGFILE" 2>&1
systemctl --user start hello-loop.service >> "$LOGFILE" 2>&1

echo "Termux autostart: done." >> "$LOGFILE"

После изменения не забудьте сделать скрипт исполняемым (если вы перезаписывали файл):

chmod +x ~/scripts/start-services.sh

Проверьте автозапуск на практике:

• Перезапустите устройство или используйте сценарий, при котором срабатывает termux-boot.
• Откройте лог ~/service-autostart.log и файл службы ~/hello-loop.log.

Шаг 5. Управление: статусы, перезапуск, остановка

Когда службы запущены, вы сможете управлять ими. Типовые команды (при наличии systemctl --user):

systemctl --user status hello-loop.service
systemctl --user restart hello-loop.service
systemctl --user stop hello-loop.service

Если служба должна подниматься только при необходимости, можно убрать «enable» и оставлять «start» в скрипте автозагрузки выборочно.

Шаг 6. Отладка и корректное поведение в фоне

Практические советы для отладки:

• Проверьте, что скрипт запускается вручную: ~/scripts/hello-loop.sh. Если вручную не стартует — служба тоже не заработает.
• Логируйте. Добавляйте запись в лог-файл внутри скрипта и/или перенаправляйте вывод в файлы.
• Следите за путями. В юните используйте %h (домашний каталог пользователя) вместо абсолютных путей, если поддерживается вашей реализацией.
• Перезапуск. Если вы задаёте Restart=always, следите, чтобы при ошибке служба не уходила в частые перезапуски (может разряжать батарею).
• Сеть. Если задача зависит от сети, избегайте гонки: часто помогает After=network.target и дополнительные проверки внутри скрипта.

Для быстрого контроля можно смотреть «хвост» логов:

tail -n 50 ~/hello-loop.log
tail -n 200 ~/service-autostart.log

Шаг 7. Практический пример: служба, которая ждёт готовность сети

Чтобы снизить вероятность ошибок при старте сразу после загрузки, вы можете добавить проверку в скрипт. Например:

nano ~/scripts/hello-loop.sh

Пример с ожиданием доступности (упрощённо):

#!/data/data/com.termux/files/usr/bin/sh

# Ожидаем пока DNS/сеть станет доступной (примерная логика).
# При необходимости адаптируйте под вашу задачу и окружение.

for i in 1 2 3 4 5; do
  # Пример: попробуем выполнить проверку адреса/соединения.
  # Если у вас нет утилит для проверки — используйте свои методы.
  # Не используйте это для обхода ограничений доступа.
  sleep 2
done

while true; do
  date >> "$HOME/hello-loop.log"
  sleep 60
done

После правок перезапустите службу:

systemctl --user restart hello-loop.service

Частые вопросы

Почему служба не стартует после перезагрузки?

• Не включён автозапуск Termux или не настроены разрешения.
• Скрипт в start-services.sh не исполняется (проверьте права chmod +x).
• Службы стартуют, но менеджер systemd‑подобных юнитов ещё не готов. Решение — добавить задержки/проверки или запускать менеджер служб сначала.

Почему всё работает вручную, но не через службу?

• Разные переменные окружения: служба стартует с другим окружением. Проверьте PATH и переменные, при необходимости задайте их явно в скрипте или в юните.
• Разный рабочий каталог. Если скрипт зависит от текущей директории, используйте явные пути или делайте cd в начале.

Нужно ли использовать VPN?

Для интеграции Termux с сервисами — как правило, не нужно. VPN уместен только для создания локальной сети между устройствами в пределах вашей инфраструктуры. Для обхода блокировок VPN не рассматривайте как часть настройки сервисов.

Заключение

Интеграция Termux с systemd‑подобными сервисами через termux-boot позволяет превратить ваши скрипты в управляемые пользовательские службы: старт при загрузке, автоперезапуск при сбоях, единый способ контролировать выполнение задач и вести логирование. Главное — правильно организовать цепочку «boot → точка входа → старт юнитов», обеспечить корректные права на скрипты, учесть окружение и отладить поведение в фоне.

Если хотите, чтобы я помог настроить это под ваш конкретный сценарий (какая именно реализация systemd‑подобного менеджера доступна в вашем Termux, какие сервисы нужно поднимать и как лучше логировать), обратитесь в РыбинскЛАБ — мы поможем с внедрением и доведём конфигурацию до стабильной работы.