Как сервис из systemd начал использоваться в CRON?

Я арендовал VPS на Ubuntu, настроил файрвол и установил сложный пароль для SSH. На этом сервере под рутом я запустил Telegram-бота на Python с использованием aiogram, а также контейнеры для MySQL и Redis (проведено исправление ufw-docker). Скрипт <code>/root/bot/run_bot.sh</code>, который запускает бота (командой <code>python /root/bot/bot/bot.py</code>) и контейнеры, был помещен в созданный для него systemd-сервис. Я выполнил команду <code>systemctl enable telegrambot.service</code>. В течение нескольких недель всё работало без сбоев. 

Однако в какой-то момент на сервере начали работать два процесса Python вместо одного. Я заметил это, так как логи бота перестали корректно обновляться. Долго искал причину двойного автозапуска бота и выяснил, что в конце файла планировщика cron (командой <code>crontab -l</code>) появилась строка: <br/> <code>@reboot /root/bot/run_bot.sh</code>. 

Я был удивлен, так как до этого никогда не работал с cron и не имел о нём никакого представления. Доступ к серверу был только у меня, и в файле .bash_history ничего, связанного с cron, я не нашёл. В итоге, не найдя дополнительной информации, я решил закомментировать эту строку в crontab, и теперь лишний процесс Python не запускается, и всё работает хорошо. 

Буду признателен, если кто-то объяснит, как эта строчка могла появиться в crontab.
  • 5 марта 2025 г. 14:04
Ответы на вопрос 2
Ситуация, которую вы описали, действительно необычная. Вот несколько возможных объяснений, как строка `@reboot /root/bot/run_bot.sh` могла появиться в `crontab` без вашего ведома:

1. **Ошибки в конфигурации или скрипте**: Возможно, в вашем `systemd`-сервисе был какой-то сбой, который привел к тому, что он не работал корректно и пытался перезапустить ваш бот. Если в скрипте есть код, который добавляет задачи в `crontab`, это могло произойти.

2. **Совпадение с другими установками**: Возможно, вы установили какое-то программное обеспечение или пакет, который автоматически добавляет задачи в `crontab` при установке или обновлении. Например, определённые инструменты для автоматизации или резервного копирования могут делать это.

3. **Вредоносные программы**: Если сервер был подвержен какому-либо компромиссу или атаке, злоумышленник мог внедрить задачу в `crontab` для обеспечения перезапуска своего кода.

4. **Редактирование `crontab` через скрипт**: Если вы запустили какой-то сторонний скрипт, который имел права на редактирование `crontab`, он мог добавить эту строку.

5. **Взаимодействие с `systemd`**: Если ваш `systemd`-сервис был настроен некорректно, и система, проверяя его состояние, пыталась восстановить его (например, с помощью `_ExecStartPre`, `_ExecStartPost`), это также может привести к неожиданной ситуации.

Чтобы выяснить конкретную причину, вы могли бы:

- Проверить логи команд `journalctl -u telegrambot.service` для получения информации о том, почему сервис мог завершиться с ошибкой.
- Проверить изменения в `crontab` с помощью команды `grep -i cron /var/log/syslog` или соответствующего файла лога, если у вас включено логирование.
- Перепроверить безопасность вашего сервера, включая наличие вирусов или недействительного доступа.

Важно избегать использования `crontab` и `systemd` одновременно для одного и того же приложения, чтобы избежать конфликтов и двойного запуска.
Скрипт /root/bot/run_bot.sh изучал? Скорее всего добавление в крон там находится.
Похожие вопросы