OScam автозапуск через systemd: настройка сервиса

Если вы запускаете OScam вручную через SSH каждый раз после перезагрузки — это не решение, это боль. OScam systemd автозапуск решает именно эту проблему: демон стартует сам, перезапускается после краша, и вам не нужно мониторить его вручную. Ниже — рабочая конфигурация, которую я использую на нескольких Debian-серверах и Armbian-платах.

Почему именно systemd, а не init.d или cron @reboot

Короткий ответ: потому что на вашей машине, скорее всего, уже работает systemd. Проверить просто — выполните ls /run/systemd/system. Если каталог существует, systemd активен и это ваш инструмент. x86-серверы на Debian 10+, Ubuntu 18.04+, Armbian — всё это systemd по умолчанию.

На Enigma2-ресиверах и старых OpenWrt ситуация другая: там init.d или встроенный менеджер автозапуска. Если попытаться поставить туда systemd-юнит — ничего не сломается, просто файл будет лежать мёртвым грузом.

Разница между ручным запуском, rc.local и systemd

rc.local — это костыль из 2005 года. Он не умеет перезапускать процессы после падения, не имеет нормальных логов и не знает, поднялась ли сеть до того, как ваша команда выполнилась. Я видел ситуации, когда OScam запускался раньше сетевого интерфейса, не мог зарезолвить DNS читеров и падал без объяснений.

cron @reboot немного лучше, но тоже не перезапускает упавший процесс и не управляет зависимостями. Для разовой задачи — ладно. Для демона, который должен работать 24/7 — нет.

Что даёт systemd: автоперезапуск, логи, зависимости

systemd умеет три вещи, которых нет в rc.local: отслеживание зависимостей (например, «стартуй только после того, как сеть поднялась»), автоматический перезапуск при падении и централизованные логи через journalctl. Для OScam это критично — читеры по сети, DNS нужен заранее, и если процесс упал в 3 ночи, вы хотите знать почему.

Когда systemd недоступен (OpenWrt, Enigma2) и чем заменить

На OpenWrt используйте /etc/init.d/ с procd — это родной менеджер процессов для этой платформы. На Enigma2 — скрипты в /etc/enigma2/ или плагин автозапуска. Это отдельная тема, но точка входа та же: проверить ls /run/systemd/system, и если пусто — смотреть, что есть на вашей платформе.

Создание unit-файла oscam.service

Файл кладётся в /etc/systemd/system/oscam.service. Не в /lib/systemd/system/ — там системные юниты дистрибутива, которые могут перезаписаться при обновлении. /etc/systemd/system/ — ваше место.

Путь к файлу: /etc/systemd/system/oscam.service

Права на файл: владелец root, режим 644. После создания или любой правки — обязательно systemctl daemon-reload, иначе systemd будет работать со старой версией юнита из кэша.

Полный пример unit-файла с разбором каждой строки

[Unit]
Description=OScam Softcam
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/oscam -b -c /usr/local/etc/oscam -t /tmp/.oscam
Restart=always
RestartSec=5
User=oscam
Group=oscam
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Разберём по строкам. After=network-online.target + Wants=network-online.target — это пара, которую большинство копируют как попало. network.target означает «интерфейс настроен», но не «DNS работает и маршруты есть». Для OScam нужен именно network-online.target. На Armbian-платах с медленным поднятием сети это особенно важно — без этого сервис стартует, не находит DNS читеров и молча сидит без соединений.

Параметры ExecStart, путь к бинарнику и -c с конфигом

Флаг -c /usr/local/etc/oscam указывает каталог с конфигурационными файлами — там должны лежать oscam.conf, oscam.server, oscam.user и остальные. Флаг -t /tmp/.oscam задаёт директорию для временных файлов. Важный момент: если /tmp у вас в tmpfs (а на большинстве современных систем так и есть), эта директория исчезает при перезагрузке. OScam пересоздаёт её сам при старте, поэтому проблем обычно нет — но знать об этом стоит.

Про флаг -b — отдельно в FAQ ниже, это частая ловушка.

Запуск под отдельным пользователем, а не от root

Запускать OScam от root — плохая идея. Если в демоне найдут уязвимость (а история показывает, что находят), атакующий получит root на вашем сервере. Создайте системного пользователя:

useradd -r -s /sbin/nologin -d /usr/local/etc/oscam oscam
chown -R oscam:oscam /usr/local/etc/oscam
chown -R oscam:oscam /tmp/.oscam

Если используете USB-смарт-карт-ридер, пользователь oscam должен состоять в группе dialout (или plugdev в зависимости от дистрибутива): usermod -aG dialout oscam. Либо пишите udev-правило на конкретное устройство — это надёжнее, потому что устройство может появиться после старта сервиса, и тут лучше настроить правило, которое при появлении USB запускает или перезапускает юнит.

Активация и проверка сервиса

Последовательность команд строго такая. Не переставляйте местами — смысл именно в порядке.

systemctl daemon-reload после правок

systemctl daemon-reload

Это говорит systemd перечитать все юниты из /etc/systemd/system/. Без этой команды после создания или изменения файла — systemd не знает о ваших правках.

systemctl enable --now oscam

systemctl enable --now oscam

enable создаёт симлинк в /etc/systemd/system/multi-user.target.wants/oscam.service — именно так systemd запоминает, что этот сервис нужно стартовать при загрузке. Флаг --now запускает сервис сразу, не дожидаясь перезагрузки. Удобно — одна команда вместо двух.

Проверка статуса и PID через systemctl status oscam

systemctl status oscam

Нормальный вывод выглядит так: Active: active (running) since... с указанием Main PID и несколькими последними строками из лога. Если видите active (running) — всё хорошо. failed или activating — смотрите код ошибки и журнал.

Тест: перезагрузка и контроль автостарта

После того как сервис поднялся — перезагрузите сервер. Именно перезагрузку, не просто systemctl restart oscam. OScam systemd автозапуск нужно проверить в реальных условиях: после reboot подождите 30–60 секунд (на Armbian дольше, сеть медленнее) и выполните systemctl status oscam. Если видите active (running) — настройка работает.

Логи и диагностика через journalctl

Когда OScam падает в 4 утра и вы не знаете почему — journalctl ваш первый инструмент. Systemd пишет туда всё, что сервис выводит в stdout/stderr.

journalctl -u oscam -f для живого лога

journalctl -u oscam -f

Флаг -f работает как tail -f — показывает новые строки в реальном времени. Полезно при первом запуске или когда нужно проследить, что происходит в момент старта.

journalctl -u oscam --since и фильтрация по времени

journalctl -u oscam --since "2026-06-23 03:00:00" --until "2026-06-23 05:00:00"

Если сервис упал ночью и вы разбираетесь утром — фильтрация по времени незаменима. Можно также использовать --since "1 hour ago" для удобства.

Связь с logfile в oscam.conf и webif

Тут есть нюанс, который многие не замечают. Если в oscam.conf прописан параметр logfile=/var/log/oscam/oscam.log, то OScam пишет в этот файл напрямую. Systemd при этом тоже пишет в journal — всё что идёт в stdout/stderr. Получается два набора логов, которые могут расходиться по содержимому.

Мой совет: либо уберите logfile из oscam.conf и пусть всё идёт в journal, либо оставьте файл и не смотрите journalctl на предмет содержимого OScam — там будут только сообщения systemd про старт/стоп. Смешивать не стоит — запутаетесь.

Что значат коды выхода в логе systemd

В journalctl при падении сервиса вы увидите строку вида oscam.service: Main process exited, code=exited, status=1/FAILURE или status=203/EXEC. Код 203 — systemd не смог запустить бинарник. Код 1 — OScam запустился, но сам вышел с ошибкой. Разница важна: 203 — проблема на уровне systemd (путь, права), 1 — проблема внутри самого OScam (конфиг, порты, права на файлы).

Типичные ошибки автозапуска и их устранение

Вот конкретные проблемы, которые встречаются чаще всего, и как их решать.

status=203/EXEC — неверный путь к бинарнику

Код 203/EXEC означает одно из двух: либо файла по пути из ExecStart не существует, либо он существует, но без бита исполнения. Проверьте:

ls -la /usr/local/bin/oscam

Если файла нет — значит OScam установлен в другое место. Используйте which oscam или find / -name oscam -type f 2>/dev/null. Если файл есть, но нет x: chmod +x /usr/local/bin/oscam.

Permission denied на каталог конфигов или /tmp

Если сервис запускается под пользователем oscam, но каталог /usr/local/etc/oscam принадлежит root — получите Permission denied. Смотрите код 200/EXEC в логах или явное сообщение об ошибке доступа.

chown -R oscam:oscam /usr/local/etc/oscam
chmod 750 /usr/local/etc/oscam

С SELinux или AppArmor ситуация сложнее. AppArmor может блокировать запуск бинарника из нестандартного пути (/usr/local/bin/ вместо /usr/bin/). Проверьте dmesg | grep apparmor или aa-status. Либо создайте профиль, либо временно переведите в complain-режим для диагностики: aa-complain /usr/local/bin/oscam.

Сервис стартует раньше сети — DNS читеров не резолвится

Это самая частая причина, по которой OScam «работает вручную, но не работает при автостарте». При ручном запуске через SSH сеть уже поднята. При автостарте — не факт.

Решение: убедитесь, что в юните стоит After=network-online.target и Wants=network-online.target. Дополнительно на Armbian-платах с systemd-networkd включите службу ожидания сети:

systemctl enable systemd-networkd-wait-online.service

На системах с NetworkManager вместо этого используйте NetworkManager-wait-online.service. Проверить, какой менеджер сети используется: systemctl status NetworkManager или systemctl status systemd-networkd.

Бесконечный цикл рестартов и StartLimitBurst

Если OScam падает быстро (например, не может найти конфиг), systemd перезапускает его снова и снова. После определённого числа попыток systemd блокирует сервис: oscam.service: Start request repeated too quickly. По умолчанию — 5 попыток за 10 секунд.

Чтобы расширить лимит или убрать блокировку, добавьте в секцию [Service]:

StartLimitIntervalSec=60
StartLimitBurst=10

Это даёт 10 попыток за 60 секунд. Если проблема в конфиге — это не поможет сервису заработать, но даст больше времени для диагностики. Чтобы разблокировать уже остановленный сервис: systemctl reset-failed oscam && systemctl start oscam.

Отдельный случай — несколько экземпляров OScam на одном сервере. Например, один слушает порт 11000 для одного набора конфигов, второй — порт 11001 для другого. Для этого используется шаблонный юнит: создайте файл /etc/systemd/system/[email protected] и в ExecStart используйте %i для подстановки имени экземпляра:

ExecStart=/usr/local/bin/oscam -c /usr/local/etc/oscam-%i -t /tmp/.oscam-%i

Тогда systemctl start oscam@server1 запустит экземпляр с конфигом из /usr/local/etc/oscam-server1/.