Почему мой crontab не инициировал?

Скопируйте свои необычные точечные файлы автоволшебно

Модульный .bashrc-> .bashrc.d

mkdir -p ~/.bashrc.d
cat<<'EOF' >> ~/.bashrc
echo ""
echo -n ".bashrc.d warming up: "
for script in ~/.bashrc.d/* ; do
  if [ -x "$script" ] ; then
    echo -n "${script##*/} "
    . "$script"
  fi
done
echo ""
echo ""
echo "  All systems are go."
echo ""
EOF

Более безопасная комната, совместимая с Linux и Mac OS X

rm() {
  local src
  local final_status=0

  for src in "$@"; do
    # Process only non command-line arguments.
    if [[ "$src" != -* ]]; then
      local trash="$HOME/.Trash"
      if [ ! -e "$src" ]; then
        echo "Safer rm: $src: No such file or directory."
        final_status=1
      fi
      # Create the trash directory if needed.
      if [ ! -d "$trash" ]; then
        # Assume Mac trash, but it'll work on *nix too.
        mkdir -p "$trash"
        if [ ! -d "$trash" ]; then
          echo "Safer rm: Unable to create trash directory $trash"
          echo ""
          echo "   Nothing moved or deleted.  Consider carefully:"
          echo ""
          echo "      /bin/rm -rf $src"
          return 1
        fi
      fi
      local dest="$trash/${src##*/}"

      # Find a filename combination which does not already exist.
      if [ -e "$dest" ]; then
        # Try appending ISO datetime.
        dest="$dest.$(date +%Y-%m-%dT%H-%M-%S)"
        if [ -e "$dest" ]; then
          local n=1
          # Try increasing monotony.
          while [ -e "$dest.$n" ]; do
            n = $[n + 1]
          done
          dest="$dest.$n"
        fi
      fi
      echo -n "Safer rm: Trashing $src to $dest ..."
      /bin/mv "$src" "$dest"
      echo " done."
      echo ""
      echo "  To restore:  /bin/mv     '$dest' '$src'"
      echo ""
      echo "  To purge:  /bin/rm -rf '$dest'"
      echo ""
      echo ""
    fi
  done
  return $final_status
}

Супер горячий 'CD' действие

# Don't ask why I need 15 levels of cd ..

alias ..='cd ..'
alias .2='cd ../..'
alias ...='.2'
alias .3='cd ../../..'
alias .4='cd ../../../..'
alias .5='cd ../../../../..'
alias .6='cd ../../../../../..'
alias .7='cd ../../../../../../..'
alias .8='cd ../../../../../../../..'
alias .9='cd ../../../../../../../../..'
alias .10='cd ../../../../../../../../../..'
alias .11='cd ../../../../../../../../../../..'
alias .12='cd ../../../../../../../../../../../..'
alias .13='cd ../../../../../../../../../../../../..'
alias .14='cd ../../../../../../../../../../../../../..'
alias .15='cd ../../../../../../../../../../../../../../..'

Readline является Вашим истинный бог.

bind -p | egrep -v '(not|self)' # No existential jokes included.

Терминальные шрифты

После рассмотрения огромного количества шрифтов я использую 14 pt Monaco, Anti-aliased с iTerm2.

На Mac (Приложения): Попробуйте это приложение, которое дает привязки клавиш.

KeyCue (TM) (r) (c) ($) дает контекст ПОЧТИ ЛЮБОГО запущенного приложения путем простого содержания команды.

29
13.04.2017, 15:22
8 ответов

Существуют реализации cron (не все они, и я не помню, с которым бесцеремонно, но я встретился один в соответствии с Linux), что проверка на обновленные crontab файлы каждую минуту на минуте, и не рассматривает новые записи до следующей минуты. Поэтому crontab может занять до двух минут для разжигания впервые. Это может быть тем, что Вы наблюдали.

23
27.01.2020, 19:38
  • 1
    я предположил бы Солярис или возможно ранний Солярис. У меня есть привычка к тому, чтобы заставлять запись крона выполнить 3-5 минут в будущем, когда я тестирую сценарий от crontab записи, потому что я раньше дурачился этим поведением все время. –  Bruce Ediger 18.03.2011, 00:19
  • 2
    fcron делает это также. –  phunehehe 18.03.2011, 03:36
28
27.01.2020, 19:38
  • 1
    После моего cronjob существует пустая строка. прохладный –  ripper234 17.03.2011, 20:13
  • 2
    Не пустая строка, а новая строка в конце последней строки. Текстовый файл, как предполагается, состоит из последовательности строк, каждый завершенный новой строкой, таким образом, любые непустые концы текстового файла с символом новой строки. Некоторые утилиты ничего не обрабатывают после последней новой строки в файле. –  Gilles 'SO- stop being evil' 17.03.2011, 21:56
  • 3
    Это - вопрос условий, средства "символа новой строки" "после этой символьной новой строки запуска текста". Таким образом, 0 байтов между последней новой строкой и EOF также можно рассмотреть как пустую строку ("строка, которая содержит 0 символов"), –  gelraen 17.03.2011, 22:29

Кажется, что это фиксируется. В следующий раз попытайтесь регистрировать STDERR также. Следующее только зарегистрируется к STDOUT, не STDERR:

* * * * * echo hi >> /home/myusername/test

Попытайтесь удостовериться, что существует явный пункт для STDERR также. Иначе STDERR может быть отправлен по электронной почте пользователю (предполагающий, что электронная почта работает), или никуда может не пойти вообще, в зависимости от того, как Крон настроен.

* * * * * echo hi >> /home/myusername/test 2> /home/myusername/test.stderr

Мое предпочтение состоит в том, чтобы отправить вывод cronjob в системный журнал. Тем путем я использую в своих интересах любую существующую инфраструктуру системного журнала (централизованные системные журналы, Splunk, вращение журнала, уже поддерживаемое, легко сравнить сообщения в/var/log/messages и/var/log/cronjob, и т.д.), и я не массово рассылаю системных администраторов (меня) с ненужными электронными письмами.

* * * * * echo hi >> /home/myusername/test 2>&1 | /usr/bin/logger -t mycronjob
5
27.01.2020, 19:38

Ваша строка крона хорошо работает на моем компьютере, когда я изменяюсь myusernae кому: phunehehe. Существует несколько способов узнать что случилось с Вашей системой.

Крон обычно отправляет почту пользователю, когда существует что-то не так. Если Вы видите сообщение, "У Вас есть почта", используют почтовый клиент для проверки ящика входящих сообщений. Или, зарегистрируйтесь в своем корневом каталоге, может быть названный файл dead.letter там.

Можно проверить /var/log/ для записей, касающихся крона. На моем компьютере файл журнала в /var/log/cron/current (требует корневого доступа).

Если у Вас есть корневой доступ, можно остановить демона крона и запустить его в режиме отладки. Например, я использовал бы (изменение fcron к имени Вашего демона):

killall fcron
fcron --foreground --debug
1
27.01.2020, 19:38
  • 1
    Как я узнаю имя своего демона? –  ripper234 17.03.2011, 19:05
  • 2
    @ripper234 ps -ef | grep cron и необходимо видеть строку для крона. Проверьте страницу справочника крона для наблюдения флага для отладки. Вероятно, что Вы используете Крон Vixie, в этом случае флаг отладки -x. Уничтожьте процесс крона и запустите его снова с дополнительного флага. –  phunehehe 18.03.2011, 03:34

Скорее всего, когда крон перестал работать, он генерирует электронное письмо к идентификатору пользователя задания крона на том компьютере. Если у Вас не будет MTA, работающего над Вашим компьютером, или Вы не читаете или пересылаете ту почту где-то в другом месте, то Вы не будете видеть, что сообщение, даже если MTA будет работать.

Хороший способ получить ошибки Вашего crontab через почту состоит в том, чтобы заставить Ваш crontab быть похожим на это:

MAILTO="myemail@example.com"
* * * * * echo hi >> /home/myusernae/test

Очевидно, используйте свой адрес электронной почты, а не myemail@example.com. Это говорит крону отправлять ошибки в Ваш адрес электронной почты, а не локальную учетную запись. В частности, это полезно, если у Вас есть корень crontab (или crontab фрагмент в/etc/cron.d), что Вы хотите просто отправить вывод Вам, можно постараться не массово рассылать почтовый ящик корня или адрес пересылки корня.

1
27.01.2020, 19:38
  • 1
    , который я не знаю, настроили ли системе сервер SMTP/исходящей почты. Разногласия - то, что это не делает. –  ripper234 17.03.2011, 18:44

У меня была та же проблема - работа crontab внезапно остановилась после того, как я добавил новую запись в конце. Оказалось, что я забыл помещать новую строку после той последней строки.

Я узнал путем выдачи команды

cat /var/log/syslog | grep crontab

и вывод показал проблему:

Jul  2 08:16:01 shiva cron[1254]: (*system*) RELOAD (/etc/crontab)
Jul  2 08:16:01 shiva cron[1254]: (*system*) ERROR (Missing newline before EOF, this crontab file will be ignored)

Добавление новой строки и сохранение решили проблему.

10
27.01.2020, 19:38

У меня проблема заключалась в том, что скрипт не был исполняемым. У меня была crontab -e такая установка

* * * * * /bin/my-script.sh

И файл myscript не был исполняемым, поэтому я запустил

chmod +x my-script.sh

Сразу же я начал видеть результат, как и ожидалось.

2
27.01.2020, 19:38

Я предполагаю, что одна причина для этого может случиться так, что каталог / home / зашифрован, и когда пользователь выходит из системы, cron не может что-либо делать в этом каталоге.

см .: https://stackoverflow.com/a/40354269/1279002

1
27.01.2020, 19:38

Теги

Похожие вопросы