Так как обновление crontab моего пользователя было уничтожено. Это не первый случай, когда это произошло в этом году, и это боль, восстанавливающая его каждый раз.
Я хотел бы иметь возможность резервного копирования crontab для моего пользователя, но для этого мне нужно знать, где он хранится.
На самом деле, не рекомендуется обрабатывать эти файлы вручную. в crontab
справочная страница:
Каждый пользователь может иметь свой собственный кронтаб, и хотя
это файлы в /var/spool/cron/crontabs
, они не
предназначенный для редактирования напрямую.
Файлы под /var/spool
считаются временными / рабочими, поэтому они, вероятно, удаляются во время обновления, хотя более пристальный взгляд на cron
сценарии обновления пакета могут пролить свет на это.
Во всяком случае, всегда рекомендуется создавать резервные копии ваших записей cron или хранить их в файле в вашем домашнем каталоге.
Я полагаю, вы используете crontab -e
для создания файлов crontab на лету. Если это так, вы можете получить «копию» вашего файла crontab, выполнив crontab -l
, Труба в файл, чтобы получить «резервную копию»:
crontab -l > my-crontab
Затем вы можете отредактировать этот файл my-crontab для добавления или изменения записей, а затем «установить» его, предоставив ему crontab:
crontab my-crontab
Это делает ту же проверку синтаксиса, что и crontab -e
,
Его хранят внутри /var/spool/cron/crontabs
папку под именем пользователя.
Я, наконец, узнал Зачем мои установки crontabs и Postfix продолжали ломаться после загрузки. Это действительно глупая причина, но ...
я имел /var/spool
установленный как tmpfs
RAM-диск.
Звучит идиотски, и это так, но я следил за одним из старых SSD-настроек, чтобы продлить жизнь моего SSD. При этом я слепо /tmp
, /var/tmp
а также /var/spool
в виде tmpfs
не думая о последствиях. я думал /var/spool
было похоже /proc/
или /run/
и что это было полезно только в течение всего сеанса. Я явно ошибался.
Чтобы просмотреть все задания cron у всех пользователей вашей системы:
for user in $(cut -f1 -d: /etc/passwd)
do
echo $user
crontab -u $user -l
done
Альтернативой вашей проблеме было бы поместить их в папку cron.d и указать соответствующего пользователя в cron, как в примере:
00 01 * * * user /home/user/user-script.sh