2Xclient - очень приятное и стабильное приложение [2xclient]
http://www.2x.com/rdp-client/windows-linux-mac/
Пользовательские crontabs, заданные crontab -e или crontab -l, НЕ являются системными crontab. Пользователь crontabs хранится как файлы в / var / spool /, обычно / var / spool / cron / crontab / username
Единственный безопасный / чистый способ их редактирования - использовать crontab -e, так как он автоматически проверяет синтаксис и жалуется, если вы допустили ошибку, тем самым не позволяя вам слишком плохо перепутаться.
Однако запрос OP относится к системным скриптам cron, как к /etc/cron.daily, /etc/cron.weekly и т. д. , Обычно эти сценарии вызываются из-за того, что они находятся в файле crontab в / etc / crontab. Другой набор crontabs также находится в /etc/cron.d/*. Они, наряду со сценариями в /etc/cron.{daily, нескромно, ...} считаются «системными» кроссами.
Эти системные кроны выполняются независимо от содержимого корневого корня, даже если корень crontab полностью пуст. Эти crontabs (crontabs, а не скрипты) также немного отличаются друг от друга тем, что есть дополнительный столбец (столбец 6), где вы должны указать имя пользователя, которое должна выполнить запись. Эта колонка, конечно, не нужна в «пользовательских» хрустах.
Вы говорите, что с sudo запускаются скрипты. Проверьте, зарегистрированы ли скрипты в списке crontab root, используя sudo crontab -l, чтобы перечислить задания root.
Если скрипты root в crontab корня, то наиболее вероятными могут быть ошибки:
Путь к скрипту может быть относительным, а не абсолютным, является предпочтительным решением. Сам скрипт отмечен chmoded. Различные переменные среды не загружаются cron во время выполнения заданийЕсли скрипты не зарегистрированы в корневом каталоге root, вот пример их регистрации:
Скажем, у меня есть сценарий резервного копирования с именем backup.sh, расположенный в /root/bin `, который я хочу запускать на своей машине каждые 10 дней и является заданием системы (root's). Чтобы зарегистрировать его в корневом каталоге crontab:
Путь к скрипту может быть относительным, а не абсолютным, что является предпочтительным решением . В новой строке введите:08 22 */10 * * /root/bin/backup.sh packages directories dbs remote email &>/dev/null
Для запуска задания cron не регистрируются в 22:08 каждые 10 дней с аргументами: packages directories dbs remote email и отправляют любой вывод в /dev/null. [!d15 ]
В результате скрипт резервного копирования начнет выполняться в определенное время с помощью root и будет выполнять задание по резервному копированию различных каталогов, apt-источников, баз данных, scp на удаленный сервер в архив архива tar и отправку электронной почты администратору. Как вы можете видеть сложное задание cron успешно запущено как системная задача.