Планировщик заданий (Cron) не запускается после перезагрузки системы без входа в систему.

Вопрос или проблема

* * * * * /usr/local/bin/test.sh

#!/bin/bash  
bckdate=$(date +%Y%m%d_%H:%M:%S)  
cp /home/testuser/onedrive/testfile.txt /media/testbackup/backups/"$bckdate"  

journalctl -u cron  
testuser CRON[3004]: pam_unix(cron:session): session opened for user testuser(uid=1000) by testuser(uid=0)  
testuser CRON[3005]: (testuser) CMD (/usr/local/bin/test.sh)  
testuser CRON[3004]: pam_unix(cron:session): session closed for user testuser  

grep "/media/testbackup/backups" /proc/mounts   
/dev/nvme0n1 /media/testbackup/backups ext4 rw,nosuid,nodev,relatime,errors=remount-ro 0 0

Ответ или решение

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

Теория

Cron — это утилита в Unix-подобных операционных системах, предназначенная для автоматического выполнения заданий по расписанию. Cron-демон запустится при загрузке системы и продолжает выполнять задачи, определенные в crontab файлах, в заданное время. Cron работает по принципу, что не требует интерактивного входа пользователя, что делает его идеальным инструментом для автоматизированных скриптов и штатных заданий.

Однако, несколько факторов могут повлиять на выполнение заданий после перезапуска системы. Один из них — это доступ к файловой системе и монтирование директорий, необходимых для выполнения скриптов. Если каталоги, которые требуются для работы скрипта, не смонтированы должным образом, скрипты не смогут выполнить свои задачи. Еще один возможный фактор — это права доступа, которые могут ограничивать выполнение скриптов без интерактивного входа.

Пример

В вашем конкретном случае, cron задание настроено для выполнения скрипта /usr/local/bin/test.sh, который копирует файл из одного каталога в другой каждый раз с новым именем на основе временной метки. Вот как выглядит ваш скрипт:

#!/bin/bash  
bckdate=$(date +%Y%m%d_%H:%M:%S)  
cp /home/testuser/onedrive/testfile.txt /media/testbackup/backups/"$bckdate"  

Вы отметили, что после перезапуска системы задача не выполняется автоматически, пока вы не войдете в систему и не откроете "целевую папку" в файловом проводнике. Это указывает на проблему с монтированием файловой системы.

После дальнейшего исследования с использованием команды grep "/media/testbackup/backups" /proc/mounts, вы подтвердили, что целевая директория смонтирована, но могла быть проблема с её доступностью сразу после перезагрузки.

Применение

Решение ваших проблем началось с пересмотра способа монтирования целевой директории. Вы отметили, что корректировка монтирования с /media/testbackup/backups на /mnt/testbackup/backups помогла в решении проблемы. Рассмотрим, почему изменение точки монтирования сыграло ключевую роль.

1. Монтирование по умолчанию и файловые системы: Директории в /media часто используются для временного монтирования съемных носителей, таких как USB-накопители, и могут иметь различные политики монтирования. Директории в /mnt же обычно используются для постоянных монтирований и имеют более предсказуемое поведение после перезапуска.

2. fstab конфигурация: Проверьте файл /etc/fstab для уверенности, что ваш раздел или устройства, которые требуют монтирования, корректно настроены для автоматической загрузки без вмешательства пользователя. Обратите внимание на такие опции, как auto (для автоматического монтирования) и nofail (чтобы загрузка системы продолжалась, даже если монтирование не удалось).

3. Правильные права доступа: Убедитесь, что у crond-демона и у пользователя, под которым выполняется скрипт, есть все необходимые права доступа к исходным и целевым директориям. Это можно сделать, проверив права доступа к директорям и файлам с помощью команд ls -l и chmod/chown, если потребуется.

4. Проверка логов: Регулярно проверяйте логи crond для обнаружения возможных ошибок. Они могут содержать полезную информацию при диагностике проблем. Логи cro

5. Автозапуск сервисов: Убедитесь, что все необходимые сервисы, от которых зависят ваши задания cron (например, сетевые службы или специализированные модули ядра), автоматически запускаются при старте системы. Используйте systemctl для управления и проверки этих сервисов.

В результате, ваша проблема действительно заключалась в неправильной точке монтирования, что влияло на доступность директории сразу после загрузки системы. Приведение монтирования к правильной схеме решило проблему с выполнением cron-задания. Надеемся, это руководство помогло вам понять основную причину проблемы и возможные решения для таких ситуаций в будущем.

Если у вас возникнут дополнительные вопросы или потребуется более глубокое расследование в рамках системной автоматизации, не стесняйтесь обращаться.