Не работает cron mac os

Обновлено: 03.07.2024

Вопрос. cron должен работать в OSX El Capitan?

Кажется, это работает для меня, но я думаю, что вам нужно указать редактор:

env EDITOR=nano crontab -e

Добавьте свои кроны, а затем сохраните файл с указанным именем и местоположением. В моем случае это файл в /tmp/crontab.xxxx .

Тогда, если вы сделаете crontab -l , вы должны увидеть свои кроны.

Это еще один ответ для тех, кто находит это через Google. Там не так много результатов.

Для меня каким-то образом /usr/lib/cron была связана с /var/at (о которой я даже никогда не слышал…), а /var/at имел файл cron.allow , в котором не было моего имени пользователя, поэтому запустил Sudo vi /var/at/cron.allow и добавил свое имя пользователя (каким-то образом перенаправив echo в этот файл не сработало…) починил.

Для Mojave, Полный доступ к диску не позволяет вам изменять системные файлы (которые включают в себя данные, относящиеся к конфиденциальности, а также конфигурацию системы, такую как crontabs).

Чтобы включить доступ:

Перейти к Системные настройки > Безопасность и конфиденциальность > Конфиденциальность > Полный доступ к диску
нажмите кнопку +
Добавьте свое терминальное приложение (например, /Applications/Utilities/Terminal.app или /Applications/iTerm.app)
Перезапустите приложение терминала
Настроить cron
Необязательно, но настоятельно рекомендуется: удалить приложение терминала из Полный доступ к диску по завершении

На MacBook с использованием El Capitan (10.11.5) «cron» по-прежнему работает просто отлично.

«/usr/lib/cron.deny» является значением по умолчанию (перечисляет только «Гость»), и «cron.allow» отсутствует. Не забывайте делать какие-либо настройки, чтобы заставить его работать (без модов init/config, ни chmod, ни file/dir не создает/удаляет и т.д.).

(Использовал 10.6. * До тех пор, пока MacBook не умер в апреле. Начал использовать 10.11 в середине мая, восстановил мой crontab после обновления 10.11.5 («конец мая»). Поэтому не знаю, работал ли cron под 10.11, или повторно включен обновлением 10.11.5.)

Попробуйте этот простой тест: «crontab -e», затем «*/5 * * * * date >> /tmp/z.date». Должны видеть новую дату каждые пять минут.

Если это работает, попробуйте "*/5 * * * * env >> /tmp/z.date.1" и проверьте вашу среду. Например, стандартная переменная PATH довольно короткая.

Кстати, "at" - это очередь пакетных заданий. «at», «batch» и «cron» часто группируются вместе, поскольку они делают вариации одного и того же.

Если вы введете cd /usr/lib/cron , то ls вы увидите, что у вас есть at.deny и cron.deny , но нет at.allow или cron.allow . Запустите Sudo nano cron.allow и введите ваши имена пользователей по одному в строке. Создать копию для at.allow . Я создал эти два файла, и он начал работать.

cron полностью пропустит все задания, пока машина спит. Попробуйте проверить настройки энергосбережения (см. Ниже).

launchd (рекомендуемая Apple альтернатива) также не запускается, пока машина спит, но не пропускает задания. Вместо этого задания запускаются, когда машина просыпается.

Согласно Apple, cron был объявлен устаревшим некоторое время назад. Должно быть, они наконец-то вытащили вилку из GM Эль-Капитана. Apple предлагает использовать launchd вместо cron. Вот учебник: launchd

Некоторые опытные пользователи Mac могли заметить, что определенные сценарии оболочки с cron, cron jobs и crontab либо не работают вообще, либо не могут работать должным образом в новейших версиях MacOS, особенно Mojave 10.14, Catalina 10.15 и новее. В зависимости от ситуации, это может сопровождаться ошибкой разрешений, ошибкой «операция не разрешена» или скриптом или заданием cron может просто незаметно завершиться сбой в фоновом режиме. Хотя существует множество причин, по которым задание cron может завершиться ошибкой, строгие меры безопасности в последних выпусках MacOS также могут быть виноваты и вызывать проблемы у некоторых пользователей.

В этой статье рассматривается решение проблем с разрешениями cron в последних версиях MacOS, включая MacOS Catalina и Mojave.

Обратите внимание, что это предназначено только для опытных пользователей Mac. Если вы не используете cron и у вас есть проблемы, связанные с разрешениями, вы не захотите вносить какие-либо из этих изменений.

Как предоставить cron полный доступ к диску в MacOS

Если cron имеет проблемы с разрешениями в последних версиях MacOS, вам необходимо предоставить cron полный доступ к диску на Mac. Вот как это сделать:

Откройте «Системные настройки» в меню  Apple, затем выберите «Безопасность и конфиденциальность».
Перейдите на вкладку «Конфиденциальность», затем выберите «Полный доступ к диску» в опциях бокового меню.
Щелкните значок замка в углу и войдите в систему с паролем администратора, чтобы предоставить разрешение на изменение настроек полного доступа к диску.
Теперь в Finder в MacOS откройте меню «Перейти» и выберите «Перейти к папке».

Как упоминалось ранее, это только для опытных пользователей, и вы не должны предоставлять приложениям, процессам или чему-либо еще Полный доступ к диску, если вы точно не знаете, что делаете и почему вы это делаете. Cron может автоматически запускать процессы с полным корневым доступом в фоновом режиме на Mac, что имеет очевидное законное использование, а также последствия для безопасности, поэтому, если вам не нужна эта возможность, вам не следует изменять этот параметр.

Вы всегда можете отозвать полный доступ к диску в MacOS в любое время, вернувшись к настройкам и изменив соответствующие настройки. Точно так же вы также можете настроить и контролировать, какие приложения могут получать доступ к файлам и папкам на Mac. Эти функции безопасности лучше всего оставить в покое для большинства пользователей, но опытные пользователи часто настраивают эти параметры для соответствия определенным приложениям и действиям на своих компьютерах.

Cron довольно мощный и может использоваться для всех видов автоматизации, резервного копирования, создания сценариев и других расширенных действий. Вы всегда можете проверить crontab на наличие скриптов и изменить редактор crontab по умолчанию, если хотите.

Помогло ли это решить какие-либо проблемы cron, с которыми вы сталкивались в новых версиях Mac OS? У вас есть какие-нибудь особые советы или хитрости для cron? Делитесь своими мыслями и впечатлениями в комментариях.

Как я могу заставить мой Mac (с самой последней ОС) выполнять задачу автоматически один раз в день? Например, я бы хотел, чтобы он автоматически загружал копию этого учебника по алгебре с открытым исходным кодом раз в день. У меня есть ощущение, что какая-то комбинация wget и cron должна работать, но, прогуглив и прочитав документацию cron, я просто не смог заставить ее работать правильно.

Я предлагаю вам не использовать Crontab, а вместо этого научиться использовать Launchd, как уже предлагалось.

Это должно работать каждый день в 23:55

Обновить

Вы должны указать выходное местоположение WGET с -O /path/to/file

Вам не обязательно нужен sudo. Индивидуальные пользователи могут иметь свои собственные crontabs

Демон cron может быть активирован простым:

Затем желательно ввести полный путь к вашему / usr / local / bin / wget (или где бы он ни находился). Крон не знает о $ PATH вашего пользователя. Надеюсь, это поможет.

Вы можете использовать Cronnix, который является бесплатным графическим интерфейсом для cron:

cronnix был официально снят с производства. Он может перестать работать правильно (или вообще не работать) в последних версиях macOS.

Если вы находите синтаксис командной строки (и т. Д.) Слишком запутанным / загадочным, вы можете обратиться к инструменту с графическим интерфейсом для просмотра / редактирования / создания этих заданий.

В прошлом я использовал Lingon , который теперь доступен и в Mac App Store. Мне не нужно использовать это очень часто, но это очень полезно, когда я делаю!

Более элегантным решением (чем cron) является использование уведомлений iCal + Applescript.

Сначала запустите AppleScript Editor (находится в / Application / Utilities) и вставьте следующий код:

Сохраните скрипт и выйдите из редактора applecript.

Откройте свой iCal и создайте новое событие на сегодня, установив желаемое время, выберите «повторить: каждый день» и в качестве будильника «Запустить сценарий» и выберите ваш скрипт.

Я рекомендую макароны . Его преимущество заключается в том, что когда вы запускаете задание один раз в день, оно запускается, когда ваш компьютер включен, независимо от времени. Таким образом, вы не пропустите работу, потому что компьютер был выключен в указанное время.

Macaroni - это инструмент, который обеспечивает регулярное обслуживание Mac OS X, включая процесс восстановления прав Mac OS X, а также обслуживание в стиле Unix. Вы могли бы сделать это самостоятельно, но разве у вас нет более интересных вещей, связанных с вашим временем?

Только что обновили Snow Leopard до Lion, и мои задания cron, использующие ssh, перестали работать. Похоже, что ssh-agent больше не работает должным образом.

Вот упрощенная версия моего скрипта, вызываемого из cron, который отлично работал в Snow Leopard:

При запуске из командной строки этот сценарий работает должным образом.

При запуске из cron не работает. Вывод ssh-agent выглядит нормально:

Но ssh -vvv вывод показывает, что он не работает, когда нужно прочитать закрытый ключ:

Другими словами, он ожидает, что я введу кодовую фразу для

/.ssh/id_dsa , что, конечно, не работает в cron.

Все это работало в Snow Leopard.

Обратите внимание, что у меня есть настройка Keychain Access, чтобы ssh , ssh-agent , и ssh-add разрешено читать мою кодовую фразу для моего .ssh/id_dsa file - в результате я могу использовать SSH из командной строки терминала без необходимости вводить кодовую фразу.

Это проблема, которую мне нужно запустить ssh-add в какой-то момент моего входа в систему? Запуск его из стандартного приглашения bash не помогает в работе cron (хотя, как ни странно, он запрашивает мою парольную фразу . что, как мне кажется, не обязательно в конфигурации Keychain Access).

ПРИМЕЧАНИЕ 2. - Я понимаю, что ключи SSH без ключевой фразы решат мою проблему; однако я бы предпочел не идти по этому пути.

cron больше нет. Смотрите тег launchd здесь для получения всевозможной помощи (сделайте шаг - он обрабатывает порты, среду и многое другое, намного лучше, чем когда-либо делал cron) - я действительно надеюсь, что у кого-то есть решение, но cron mojo здесь наверняка устаревает .
cron все еще работает в Lion . но вы правы, я должен сделать ход. Однако файл XML из 10+ строк для выполнения работы с одной ЛИНИЕЙ crontab довольно неубедителен. Может быть, через 10 лет они переключат файлы plist на JSON, и будет много радости, а через 10 лет они вернутся к crontab, и седобородые BSD будут смеяться. Полагаю, к тому времени я стану седобородым BSD .
Только что перешел на launchd, прелесть работает. Вызываемый скрипт вообще не должен взаимодействовать с ssh-agent - вы можете сразу перейти к команде ssh после хэшбэнга. Если бы на ваш комментарий был ответ, я бы его принял =)
JSON определенно превосходит XML во многих случаях, но все предыдущие списки, вероятно, вызвали проблему. Я просто рад, что у нас есть унифицированная, эффективная и структурированная замена на основе данных. cron и, безусловно, служил нам целую вечность!
Я все время искал дополнительные веб-ресурсы, но всегда возвращался к этому посту. Наверняка у кого-то есть больше, чтобы внести свой вклад в обсуждение? Я попытался использовать простой список для запуска сценария оболочки, но затем mailx не отправляет мои уведомления. Мне до сих пор нравится cron, и я все время использую его в Ubuntu. Я не хочу возвращаться к 10.6, но меня убивает эта проблема. Мне не нравится, когда меня заставляют использовать launchctl и мне приходится изучать то, что мне кажется очень обширным фреймворком, в основном автоматизирующим сценарии оболочки. У кого-нибудь есть новые идеи?

Я понял, что всем, кто попадает на эту страницу, следует опубликовать ответ:

Использование launchd вместо cron действительно решает проблему с авторизацией. Задания, запускаемые пользователем (которые выполняются только при входе в систему), правильно используют информацию агента SSH, которая была разблокирована через связку ключей как часть входа в систему (как часть стандартного управления ключами OS X, другое программное обеспечение не требуется).

Чтобы свести к минимуму мое взаимодействие с launchd, я создал одно задание launchd, которое вызывает сценарий bash. Таким образом, я могу просто отредактировать сценарий, не имея дела с launchd.

Вот файл launchd:

Я сохранил файл в <?php

/Library/LaunchAgents/com.mycron.hourly.plist , а затем загрузил его:

После загрузки он будет запускаться сразу же, а затем снова каждые 60 минут.

2 Действительно, cron устарел, по крайней мере, в Lion. Престижность за то, что нашел ответ - сначала сложно взломать launchctl.

Добавление следующего кода в сценарий оболочки bash решит проблему:

Заменить your_user с вашим собственным именем пользователя.

Этот код устанавливает правильное значение для SSH_AUTH_SOCK что информирует ssh или scp о том, как общаться с ssh-agent когда сценарий оболочки запускается из cron .

Это решило проблему, с которой я столкнулся, когда scp не работал через launchd в сценарии оболочки, несмотря на то, что он работал нормально через обычную командную строку (iTerm или Терминал). Отличный совет.
Для протокола, в El Captain 10.11.2: zsh: no matches found: /tmp/launch-*/Listeners

Я ожидал, что усиленная безопасность, такая как песочница, и изменения для дальнейшего перехода на 64-битную версию вызывают неожиданное горе.

Сам по себе это не ответ, но в наши дни Launchd получает всю любовь от Apple.

Это не решает проблему cron, но работает более стабильно, и с ним может помочь больше людей.

Очень хороший ответ. Спасибо, что разместили это.

Для тех, кто обнаруживает это сейчас, пытается сделать эту работу в El Capitan и по-прежнему не хочет превращать ваше однострочное задание cron в сценарий launchd, ответ Вернера Антвейлера все еще работает, но путь изменился. Ниже сработало для меня:

ПРИМЕЧАНИЕ: не забудьте заменить your_user своим именем пользователя!

Читайте также: