Вопросы Теги

Как я могу использовать cron для планирования сценария, который реализует переход на летнее время в приложение, не поддерживающее DST, когда мой сервер автоматически использует DST?

Чтобы добавить | меньше в конце командной строки, это уже функция по умолчанию в рыбе, используя Alt-p

http://fishshell.com/user_doc/index.html#editor

Вы можете создать функцию для этого, если хотите: 

function __fish_less
       commandline -i -- "|less"
end

bind \ey __fish_less

Я не уверен, что вам нужно избежать | сделайте несколько тестов ...

EDIT:

Что касается добавления, подсказка в командной строке говорит: 

* -a or --append do not remove the current commandline, append the specified string at the end of it
* -i or --insert do not remove the current commandline, insert the specified string at the current cursor position
* -r or --replace remove the current commandline and replace it with the specified string (default)

Итак, чтобы добавить, а не вставлять команду, я предположим, вы должны использовать -a

5
задан 5 September 2010 в 02:21

18 ответов

Ответ лежит в источниках cron (которые вы можете получить с помощью apt-get source cron), особенно в основном цикле на строках 159-272 файла cron.c.

crond спит для минуту, затем просыпается и запрашивает системное время, сравнивая его со своей собственной идеей времени (т. е. в какое время было бы, если бы ничего не изменило часы). Исходя из разницы между фактическим и ожидаемым временем, crond предпринимает различные действия; два из них имеют значение в вашем случае:

Время перескочило вперед более 5 минут, но менее 3 часов (начинается DST): cron запускает задания подстановочных знаков, запланированные в фактическое время, и любое задание, запланированное на фиксированное время между вычисленным временем и фактическим временем. Соответствующий источник находится в строках 221-247: 
  /*
   * case 2: timeDiff is a medium-sized positive number,
   * for example because we went to DST run wildcard
   * jobs once, then run any fixed-time jobs that would
   * otherwise be skipped if we use up our minute
   * (possible, if there are a lot of jobs to run) go
   * around the loop again so that wildcard jobs have
   * a chance to run, and we do our housekeeping
   */
  Debug(DSCH, ("[%d], DST begins %d minutes to go\n",
      getpid(), timeRunning - virtualTime))
  /* run wildcard jobs for current minute */
  find_jobs(timeRunning, &database, TRUE, FALSE);


  /* run fixed-time jobs for each minute missed */ 
  do {
     if (job_runqueue())
             sleep(10);
     virtualTime++;
     find_jobs(virtualTime, &database, FALSE, TRUE);
     set_time();
  } while (virtualTime< timeRunning &&
      clockTime == timeRunning);
  break;
Время прошло менее 3 часов (заканчивается DST): просто запускайте задания для подстановочных знаков, пропустите задания с фиксированным расписанием, так как они уже запущены. Соответствующий источник находится в строках 247-258: 
/*
 * case 3: timeDiff is a small or medium-sized
 * negative num, eg. because of DST ending just run
 * the wildcard jobs. The fixed-time jobs probably
 * have already run, and should not be repeated
 * virtual time does not change until we are caught up
 */
Debug(DSCH, ("[%d], DST ends %d minutes to go\n",
    getpid(), virtualTime - timeRunning))
find_jobs(timeRunning, &database, TRUE, FALSE);
break;

Итак, при входе в DST у вас не должно возникнуть проблемы: ваш скрипт будет запущен (либо непосредственно перед, либо сразу после скачка времени).

При выходе из DST существует риск того, что ваше (фиксированное время) задание будет пропущено, если вы планируете его точно в 1 час. Мое предложение состояло в том, чтобы запланировать прогон либо за 1 минуту до 1 часа, либо в 2 часа (или после).

3
ответ дан 26 May 2018 в 01:23

Ответ лежит в источниках cron (которые вы можете получить с помощью apt-get source cron), особенно в основном цикле на строках 159-272 файла cron.c.

crond спит для минуту, затем просыпается и запрашивает системное время, сравнивая его со своей собственной идеей времени (т. е. в какое время было бы, если бы ничего не изменило часы). Исходя из разницы между фактическим и ожидаемым временем, crond предпринимает различные действия; два из них имеют значение в вашем случае:

Время перескочило вперед более 5 минут, но менее 3 часов (начинается DST): cron запускает задания подстановочных знаков, запланированные в фактическое время, и любое задание, запланированное на фиксированное время между вычисленным временем и фактическим временем. Соответствующий источник находится в строках 221-247: /* * case 2: timeDiff is a medium-sized positive number, * for example because we went to DST run wildcard * jobs once, then run any fixed-time jobs that would * otherwise be skipped if we use up our minute * (possible, if there are a lot of jobs to run) go * around the loop again so that wildcard jobs have * a chance to run, and we do our housekeeping */ Debug(DSCH, ("[%d], DST begins %d minutes to go\n", getpid(), timeRunning - virtualTime)) /* run wildcard jobs for current minute */ find_jobs(timeRunning, &database, TRUE, FALSE); /* run fixed-time jobs for each minute missed */ do { if (job_runqueue()) sleep(10); virtualTime++; find_jobs(virtualTime, &database, FALSE, TRUE); set_time(); } while (virtualTime< timeRunning && clockTime == timeRunning); break; Время прошло менее 3 часов (заканчивается DST): просто запускайте задания для подстановочных знаков, пропустите задания с фиксированным расписанием, так как они уже запущены. Соответствующий источник находится в строках 247-258: /* * case 3: timeDiff is a small or medium-sized * negative num, eg. because of DST ending just run * the wildcard jobs. The fixed-time jobs probably * have already run, and should not be repeated * virtual time does not change until we are caught up */ Debug(DSCH, ("[%d], DST ends %d minutes to go\n", getpid(), virtualTime - timeRunning)) find_jobs(timeRunning, &database, TRUE, FALSE); break;

Итак, при входе в DST у вас не должно возникнуть проблемы: ваш скрипт будет запущен (либо непосредственно перед, либо сразу после скачка времени).

При выходе из DST существует риск того, что ваше (фиксированное время) задание будет пропущено, если вы планируете его точно в 1 час. Мое предложение состояло в том, чтобы запланировать прогон либо за 1 минуту до 1 часа, либо в 2 часа (или после).

3
ответ дан 25 July 2018 в 23:14

Ответ лежит в источниках cron (которые вы можете получить с помощью apt-get source cron), особенно в основном цикле на строках 159-272 файла cron.c.

crond спит для минуту, затем просыпается и запрашивает системное время, сравнивая его со своей собственной идеей времени (т. е. в какое время было бы, если бы ничего не изменило часы). Исходя из разницы между фактическим и ожидаемым временем, crond предпринимает различные действия; два из них имеют значение в вашем случае:

Время перескочило вперед более 5 минут, но менее 3 часов (начинается DST): cron запускает задания подстановочных знаков, запланированные в фактическое время, и любое задание, запланированное на фиксированное время между вычисленным временем и фактическим временем. Соответствующий источник находится в строках 221-247: /* * case 2: timeDiff is a medium-sized positive number, * for example because we went to DST run wildcard * jobs once, then run any fixed-time jobs that would * otherwise be skipped if we use up our minute * (possible, if there are a lot of jobs to run) go * around the loop again so that wildcard jobs have * a chance to run, and we do our housekeeping */ Debug(DSCH, ("[%d], DST begins %d minutes to go\n", getpid(), timeRunning - virtualTime)) /* run wildcard jobs for current minute */ find_jobs(timeRunning, &database, TRUE, FALSE); /* run fixed-time jobs for each minute missed */ do { if (job_runqueue()) sleep(10); virtualTime++; find_jobs(virtualTime, &database, FALSE, TRUE); set_time(); } while (virtualTime< timeRunning && clockTime == timeRunning); break; Время прошло менее 3 часов (заканчивается DST): просто запускайте задания для подстановочных знаков, пропустите задания с фиксированным расписанием, так как они уже запущены. Соответствующий источник находится в строках 247-258: /* * case 3: timeDiff is a small or medium-sized * negative num, eg. because of DST ending just run * the wildcard jobs. The fixed-time jobs probably * have already run, and should not be repeated * virtual time does not change until we are caught up */ Debug(DSCH, ("[%d], DST ends %d minutes to go\n", getpid(), virtualTime - timeRunning)) find_jobs(timeRunning, &database, TRUE, FALSE); break;

Итак, при входе в DST у вас не должно возникнуть проблемы: ваш скрипт будет запущен (либо непосредственно перед, либо сразу после скачка времени).

При выходе из DST существует риск того, что ваше (фиксированное время) задание будет пропущено, если вы планируете его точно в 1 час. Мое предложение состояло в том, чтобы запланировать прогон либо за 1 минуту до 1 часа, либо в 2 часа (или после).

3
ответ дан 31 July 2018 в 12:37

Ответ лежит на источниках cron (которые вы можете получить apt-get source cron ), особенно в основном цикле на строках 159-272 файла cron.c [ ! d1].

crond спит в течение минуты, затем просыпается и запрашивает системное время, сравнивая его со своей собственной идеей времени (то есть в какое время это будет, если ничто не изменило часы). Исходя из разницы между фактическим и ожидаемым временем, crond предпринимает разные действия; два из них имеют значение в вашем случае:

  1. Время перескочило вперед более 5 минут, но менее 3 часов (начинается DST): cron запускает задания для подстановочных знаков, запланированные в фактическое время, и любое задание запланированное в фиксированное время между вычисленным временем и фактическим временем. Соответствующий источник находится в строках 221-247: / * * случай 2: timeDiff - это положительное число среднего размера *, например, потому что мы отправились на DST для запуска подстановочных * заданий один раз, затем запустили любые задания фиксированной занятости, которые * в противном случае будет пропущен, если мы воспользуемся нашей минутой * (возможно, если есть много заданий для запуска), переходите * вокруг цикла снова, чтобы задания на подстановочные знаки имели возможность запускать, и мы делаем домашнее хозяйство * / Debug (DSCH, («[% d], DST начинается% d минут, чтобы идти \n", getpid (), timeRunning - virtualTime)) / * запускает задания подстановки для текущей минуты * / find_jobs (timeRunning, & amp; database, TRUE, ЛОЖНЫЙ); / * запускать задания фиксированной занятости за каждую минуту пропущенных * / do {if (job_runqueue ()) sleep (10); virtualTime ++; find_jobs (virtualTime, & amp; database, FALSE, TRUE); установить время(); } while (virtualTime & lt; timeRunning & amp; clockTime == timeRunning); ломать;
  2. Время назад назад меньше 3 часов (заканчивается DST): просто запускайте задания для подстановочных знаков, пропустите задания с фиксированным расписанием, так как они уже запущены. Соответствующий источник находится в строках 247-258: / * * случай 3: timeDiff - это небольшое или среднее значение * отрицательное число, например. из-за окончания DST просто запускаются задания для подстановочных знаков. Задания с фиксированным сроком действия, вероятно, уже были выполнены и не должны повторяться * виртуальное время не изменяется, пока мы не поймаем * / Debug (DSCH, ("[% d], DST заканчивается% d минут для перехода \n" , getpid (), virtualTime - timeRunning)) find_jobs (timeRunning, & amp; database, TRUE, FALSE); ломать;

Итак, при входе в DST у вас не должно возникнуть проблемы: ваш скрипт будет запущен (либо непосредственно перед, либо сразу после скачка времени).

При выходе из DST существует риск того, что ваше (фиксированное время) задание будет пропущено, если вы запланируете точно в 1 час. Мое предложение состояло в том, чтобы запланировать прогон либо за 1 минуту до 1 часа, либо в 2 часа (или после).

3
ответ дан 2 August 2018 в 04:31

Ответ лежит на источниках cron (которые вы можете получить apt-get source cron ), особенно в основном цикле на строках 159-272 файла cron.c [ ! d1].

crond спит в течение минуты, затем просыпается и запрашивает системное время, сравнивая его со своей собственной идеей времени (то есть в какое время это будет, если ничто не изменило часы). Исходя из разницы между фактическим и ожидаемым временем, crond предпринимает разные действия; два из них имеют значение в вашем случае:

  1. Время перескочило вперед более 5 минут, но менее 3 часов (начинается DST): cron запускает задания для подстановочных знаков, запланированные в фактическое время, и любое задание запланированное в фиксированное время между вычисленным временем и фактическим временем. Соответствующий источник находится в строках 221-247: / * * случай 2: timeDiff - это положительное число среднего размера *, например, потому что мы отправились на DST для запуска подстановочных * заданий один раз, затем запустили любые задания фиксированной занятости, которые * в противном случае будет пропущен, если мы воспользуемся нашей минутой * (возможно, если есть много заданий для запуска), переходите * вокруг цикла снова, чтобы задания на подстановочные знаки имели возможность запускать, и мы делаем домашнее хозяйство * / Debug (DSCH, («[% d], DST начинается% d минут, чтобы идти \n", getpid (), timeRunning - virtualTime)) / * запускает задания подстановки для текущей минуты * / find_jobs (timeRunning, & amp; database, TRUE, ЛОЖНЫЙ); / * запускать задания фиксированной занятости за каждую минуту пропущенных * / do {if (job_runqueue ()) sleep (10); virtualTime ++; find_jobs (virtualTime, & amp; database, FALSE, TRUE); установить время(); } while (virtualTime & lt; timeRunning & amp; clockTime == timeRunning); ломать;
  2. Время назад назад меньше 3 часов (заканчивается DST): просто запускайте задания для подстановочных знаков, пропустите задания с фиксированным расписанием, так как они уже запущены. Соответствующий источник находится в строках 247-258: / * * случай 3: timeDiff - это небольшое или среднее значение * отрицательное число, например. из-за окончания DST просто запускаются задания для подстановочных знаков. Задания с фиксированным сроком действия, вероятно, уже были выполнены и не должны повторяться * виртуальное время не изменяется, пока мы не поймаем * / Debug (DSCH, ("[% d], DST заканчивается% d минут для перехода \n" , getpid (), virtualTime - timeRunning)) find_jobs (timeRunning, & amp; database, TRUE, FALSE); ломать;

Итак, при входе в DST у вас не должно возникнуть проблемы: ваш скрипт будет запущен (либо непосредственно перед, либо сразу после скачка времени).

При выходе из DST существует риск того, что ваше (фиксированное время) задание будет пропущено, если вы запланируете точно в 1 час. Мое предложение состояло в том, чтобы запланировать прогон либо за 1 минуту до 1 часа, либо в 2 часа (или после).

3
ответ дан 4 August 2018 в 21:05

Ответ лежит на источниках cron (которые вы можете получить apt-get source cron ), особенно в основном цикле на строках 159-272 файла cron.c [ ! d1].

crond спит в течение минуты, затем просыпается и запрашивает системное время, сравнивая его со своей собственной идеей времени (то есть в какое время это будет, если ничто не изменило часы). Исходя из разницы между фактическим и ожидаемым временем, crond предпринимает разные действия; два из них имеют значение в вашем случае:

  1. Время перескочило вперед более 5 минут, но менее 3 часов (начинается DST): cron запускает задания для подстановочных знаков, запланированные в фактическое время, и любое задание запланированное в фиксированное время между вычисленным временем и фактическим временем. Соответствующий источник находится в строках 221-247: / * * случай 2: timeDiff - это положительное число среднего размера *, например, потому что мы отправились на DST для запуска подстановочных * заданий один раз, затем запустили любые задания фиксированной занятости, которые * в противном случае будет пропущен, если мы воспользуемся нашей минутой * (возможно, если есть много заданий для запуска), переходите * вокруг цикла снова, чтобы задания на подстановочные знаки имели возможность запускать, и мы делаем домашнее хозяйство * / Debug (DSCH, («[% d], DST начинается% d минут, чтобы идти \n", getpid (), timeRunning - virtualTime)) / * запускает задания подстановки для текущей минуты * / find_jobs (timeRunning, & amp; database, TRUE, ЛОЖНЫЙ); / * запускать задания фиксированной занятости за каждую минуту пропущенных * / do {if (job_runqueue ()) sleep (10); virtualTime ++; find_jobs (virtualTime, & amp; database, FALSE, TRUE); установить время(); } while (virtualTime & lt; timeRunning & amp; clockTime == timeRunning); ломать;
  2. Время назад назад меньше 3 часов (заканчивается DST): просто запускайте задания для подстановочных знаков, пропустите задания с фиксированным расписанием, так как они уже запущены. Соответствующий источник находится в строках 247-258: / * * случай 3: timeDiff - это небольшое или среднее значение * отрицательное число, например. из-за окончания DST просто запускаются задания для подстановочных знаков. Задания с фиксированным сроком действия, вероятно, уже были выполнены и не должны повторяться * виртуальное время не изменяется, пока мы не поймаем * / Debug (DSCH, ("[% d], DST заканчивается% d минут для перехода \n" , getpid (), virtualTime - timeRunning)) find_jobs (timeRunning, & amp; database, TRUE, FALSE); ломать;

Итак, при входе в DST у вас не должно возникнуть проблемы: ваш скрипт будет запущен (либо непосредственно перед, либо сразу после скачка времени).

При выходе из DST существует риск того, что ваше (фиксированное время) задание будет пропущено, если вы запланируете точно в 1 час. Мое предложение состояло в том, чтобы запланировать прогон либо за 1 минуту до 1 часа, либо в 2 часа (или после).

3
ответ дан 6 August 2018 в 04:36

Ответ лежит на источниках cron (которые вы можете получить apt-get source cron ), особенно в основном цикле на строках 159-272 файла cron.c [ ! d1].

crond спит в течение минуты, затем просыпается и запрашивает системное время, сравнивая его со своей собственной идеей времени (то есть в какое время это будет, если ничто не изменило часы). Исходя из разницы между фактическим и ожидаемым временем, crond предпринимает разные действия; два из них имеют значение в вашем случае:

  1. Время перескочило вперед более 5 минут, но менее 3 часов (начинается DST): cron запускает задания для подстановочных знаков, запланированные в фактическое время, и любое задание запланированное в фиксированное время между вычисленным временем и фактическим временем. Соответствующий источник находится в строках 221-247: / * * случай 2: timeDiff - это положительное число среднего размера *, например, потому что мы отправились на DST для запуска подстановочных * заданий один раз, затем запустили любые задания фиксированной занятости, которые * в противном случае будет пропущен, если мы воспользуемся нашей минутой * (возможно, если есть много заданий для запуска), переходите * вокруг цикла снова, чтобы задания на подстановочные знаки имели возможность запускать, и мы делаем домашнее хозяйство * / Debug (DSCH, («[% d], DST начинается% d минут, чтобы идти \n", getpid (), timeRunning - virtualTime)) / * запускает задания подстановки для текущей минуты * / find_jobs (timeRunning, & amp; database, TRUE, ЛОЖНЫЙ); / * запускать задания фиксированной занятости за каждую минуту пропущенных * / do {if (job_runqueue ()) sleep (10); virtualTime ++; find_jobs (virtualTime, & amp; database, FALSE, TRUE); установить время(); } while (virtualTime & lt; timeRunning & amp; clockTime == timeRunning); ломать;
  2. Время назад назад меньше 3 часов (заканчивается DST): просто запускайте задания для подстановочных знаков, пропустите задания с фиксированным расписанием, так как они уже запущены. Соответствующий источник находится в строках 247-258: / * * случай 3: timeDiff - это небольшое или среднее значение * отрицательное число, например. из-за окончания DST просто запускаются задания для подстановочных знаков. Задания с фиксированным сроком действия, вероятно, уже были выполнены и не должны повторяться * виртуальное время не изменяется, пока мы не поймаем * / Debug (DSCH, ("[% d], DST заканчивается% d минут для перехода \n" , getpid (), virtualTime - timeRunning)) find_jobs (timeRunning, & amp; database, TRUE, FALSE); ломать;

Итак, при входе в DST у вас не должно возникнуть проблемы: ваш скрипт будет запущен (либо непосредственно перед, либо сразу после скачка времени).

При выходе из DST существует риск того, что ваше (фиксированное время) задание будет пропущено, если вы запланируете точно в 1 час. Мое предложение состояло в том, чтобы запланировать прогон либо за 1 минуту до 1 часа, либо в 2 часа (или после).

3
ответ дан 7 August 2018 в 22:46

Ответ лежит на источниках cron (которые вы можете получить apt-get source cron ), особенно в основном цикле на строках 159-272 файла cron.c [ ! d1].

crond спит в течение минуты, затем просыпается и запрашивает системное время, сравнивая его со своей собственной идеей времени (то есть в какое время это будет, если ничто не изменило часы). Исходя из разницы между фактическим и ожидаемым временем, crond предпринимает разные действия; два из них имеют значение в вашем случае:

  1. Время перескочило вперед более 5 минут, но менее 3 часов (начинается DST): cron запускает задания для подстановочных знаков, запланированные в фактическое время, и любое задание запланированное в фиксированное время между вычисленным временем и фактическим временем. Соответствующий источник находится в строках 221-247: / * * случай 2: timeDiff - это положительное число среднего размера *, например, потому что мы отправились на DST для запуска подстановочных * заданий один раз, затем запустили любые задания фиксированной занятости, которые * в противном случае будет пропущен, если мы воспользуемся нашей минутой * (возможно, если есть много заданий для запуска), переходите * вокруг цикла снова, чтобы задания на подстановочные знаки имели возможность запускать, и мы делаем домашнее хозяйство * / Debug (DSCH, («[% d], DST начинается% d минут, чтобы идти \n", getpid (), timeRunning - virtualTime)) / * запускает задания подстановки для текущей минуты * / find_jobs (timeRunning, & amp; database, TRUE, ЛОЖНЫЙ); / * запускать задания фиксированной занятости за каждую минуту пропущенных * / do {if (job_runqueue ()) sleep (10); virtualTime ++; find_jobs (virtualTime, & amp; database, FALSE, TRUE); установить время(); } while (virtualTime & lt; timeRunning & amp; clockTime == timeRunning); ломать;
  2. Время назад назад меньше 3 часов (заканчивается DST): просто запускайте задания для подстановочных знаков, пропустите задания с фиксированным расписанием, так как они уже запущены. Соответствующий источник находится в строках 247-258: / * * случай 3: timeDiff - это небольшое или среднее значение * отрицательное число, например. из-за окончания DST просто запускаются задания для подстановочных знаков. Задания с фиксированным сроком действия, вероятно, уже были выполнены и не должны повторяться * виртуальное время не изменяется, пока мы не поймаем * / Debug (DSCH, ("[% d], DST заканчивается% d минут для перехода \n" , getpid (), virtualTime - timeRunning)) find_jobs (timeRunning, & amp; database, TRUE, FALSE); ломать;

Итак, при входе в DST у вас не должно возникнуть проблемы: ваш скрипт будет запущен (либо непосредственно перед, либо сразу после скачка времени).

При выходе из DST существует риск того, что ваше (фиксированное время) задание будет пропущено, если вы запланируете точно в 1 час. Мое предложение состояло в том, чтобы запланировать прогон либо за 1 минуту до 1 часа, либо в 2 часа (или после).

3
ответ дан 10 August 2018 в 10:51

Ответ лежит на источниках cron (которые вы можете получить apt-get source cron ), особенно в основном цикле на строках 159-272 файла cron.c [ ! d1].

crond спит в течение минуты, затем просыпается и запрашивает системное время, сравнивая его со своей собственной идеей времени (то есть в какое время это будет, если ничто не изменило часы). Исходя из разницы между фактическим и ожидаемым временем, crond предпринимает разные действия; два из них имеют значение в вашем случае:

  1. Время перескочило вперед более 5 минут, но менее 3 часов (начинается DST): cron запускает задания для подстановочных знаков, запланированные в фактическое время, и любое задание запланированное в фиксированное время между вычисленным временем и фактическим временем. Соответствующий источник находится в строках 221-247: / * * случай 2: timeDiff - это положительное число среднего размера *, например, потому что мы отправились на DST для запуска подстановочных * заданий один раз, затем запустили любые задания фиксированной занятости, которые * в противном случае будет пропущен, если мы воспользуемся нашей минутой * (возможно, если есть много заданий для запуска), переходите * вокруг цикла снова, чтобы задания на подстановочные знаки имели возможность запускать, и мы делаем домашнее хозяйство * / Debug (DSCH, («[% d], DST начинается% d минут, чтобы идти \n", getpid (), timeRunning - virtualTime)) / * запускает задания подстановки для текущей минуты * / find_jobs (timeRunning, & amp; database, TRUE, ЛОЖНЫЙ); / * запускать задания фиксированной занятости за каждую минуту пропущенных * / do {if (job_runqueue ()) sleep (10); virtualTime ++; find_jobs (virtualTime, & amp; database, FALSE, TRUE); установить время(); } while (virtualTime & lt; timeRunning & amp; clockTime == timeRunning); ломать;
  2. Время назад назад меньше 3 часов (заканчивается DST): просто запускайте задания для подстановочных знаков, пропустите задания с фиксированным расписанием, так как они уже запущены. Соответствующий источник находится в строках 247-258: / * * случай 3: timeDiff - это небольшое или среднее значение * отрицательное число, например. из-за окончания DST просто запускаются задания для подстановочных знаков. Задания с фиксированным сроком действия, вероятно, уже были выполнены и не должны повторяться * виртуальное время не изменяется, пока мы не поймаем * / Debug (DSCH, ("[% d], DST заканчивается% d минут для перехода \n" , getpid (), virtualTime - timeRunning)) find_jobs (timeRunning, & amp; database, TRUE, FALSE); ломать;

Итак, при входе в DST у вас не должно возникнуть проблемы: ваш скрипт будет запущен (либо непосредственно перед, либо сразу после скачка времени).

При выходе из DST существует риск того, что ваше (фиксированное время) задание будет пропущено, если вы запланируете точно в 1 час. Мое предложение состояло в том, чтобы запланировать прогон либо за 1 минуту до 1 часа, либо в 2 часа (или после).

3
ответ дан 13 August 2018 в 17:26

Вы можете попытаться переключить UTC=no, если это yes или наоборот в /etc/default/rcS. Для этого запустите: 

gksu gedit /etc/default/rcS
Измените UTC=no на UTC=yes или смените UTC=yes на UTC=no.

Сохраните файл, закройте текстовый редактор и перезагрузите компьютер.

0
ответ дан 26 May 2018 в 01:23
  • 1
    Не могу этого сделать! В самом худшем случае мой сценарий для обновления базы данных веб-форумов, чтобы переключить всех на летнее время (т. Е. Показывать UTC, а не UTC + 1), будет выполняться в 2 часа ночи, а затем снова (поскольку я установил часы назад на 1 утра). Альтернативой является то, что она не запускается, так как ОС может мгновенно вернуться к 1:00, а мое обновление работает через час. Я не хочу перезагружаться, и я, конечно, не хочу рисковать перезагрузкой дважды. Мне просто нужно определить, как ОС будет интерпретировать время моего хронометра, учитывая, что сервер также переключает BST! – Neil Trodden 5 September 2010 в 03:16
  • 2
    почему бы не создать небольшой скрипт, который создает файл при первом запуске и запускается только в том случае, если файл отсутствует? поэтому cron может вызывать скрипт 2x, но скрипт заметит, и логика выполняется только 1 раз. – aatdark 5 September 2010 в 03:33
  • 3
    Я вижу обходные пути, но я думаю, что мне нужен ответ на вопрос о том, как обрабатываются временные интервалы в cron. Я часто работаю над тем, что я не могу заставить работать, но я хотел бы также увеличить свое понимание. Комментарий +1 – Neil Trodden 5 September 2010 в 05:41

Вы можете попытаться переключить UTC=no, если это yes или наоборот в /etc/default/rcS. Для этого запустите:

gksu gedit /etc/default/rcS Измените UTC=no на UTC=yes или смените UTC=yes на UTC=no.

Сохраните файл, закройте текстовый редактор и перезагрузите компьютер.

0
ответ дан 25 July 2018 в 23:14
  • 1
    Не могу этого сделать! В самом худшем случае мой сценарий для обновления базы данных веб-форумов, чтобы переключить всех на летнее время (т. Е. Показывать UTC, а не UTC + 1), будет выполняться в 2 часа ночи, а затем снова (поскольку я установил часы назад на 1 утра). Альтернативой является то, что она не запускается, так как ОС может мгновенно вернуться к 1:00, а мое обновление работает через час. Я не хочу перезагружаться, и я, конечно, не хочу рисковать перезагрузкой дважды. Мне просто нужно определить, как ОС будет интерпретировать время моего хронометра, учитывая, что сервер также переключает BST! – Neil Trodden 5 September 2010 в 03:16
  • 2
    почему бы не создать небольшой скрипт, который создает файл при первом запуске и запускается только в том случае, если файл отсутствует? поэтому cron может вызывать скрипт 2x, но скрипт заметит, и логика выполняется только 1 раз. – aatdark 5 September 2010 в 03:33
  • 3
    Я вижу обходные пути, но я думаю, что мне нужен ответ на вопрос о том, как обрабатываются временные интервалы в cron. Я часто работаю над тем, что я не могу заставить работать, но я хотел бы также увеличить свое понимание. Комментарий +1 – Neil Trodden 5 September 2010 в 05:41

Вы можете попытаться переключить UTC=no, если это yes или наоборот в /etc/default/rcS. Для этого запустите:

gksu gedit /etc/default/rcS Измените UTC=no на UTC=yes или смените UTC=yes на UTC=no.

Сохраните файл, закройте текстовый редактор и перезагрузите компьютер.

0
ответ дан 31 July 2018 в 12:37
  • 1
    Не могу этого сделать! В самом худшем случае мой сценарий для обновления базы данных веб-форумов, чтобы переключить всех на летнее время (т. Е. Показывать UTC, а не UTC + 1), будет выполняться в 2 часа ночи, а затем снова (поскольку я установил часы назад на 1 утра). Альтернативой является то, что она не запускается, так как ОС может мгновенно вернуться к 1:00, а мое обновление работает через час. Я не хочу перезагружаться, и я, конечно, не хочу рисковать перезагрузкой дважды. Мне просто нужно определить, как ОС будет интерпретировать время моего хронометра, учитывая, что сервер также переключает BST! – Neil Trodden 5 September 2010 в 03:16
  • 2
    почему бы не создать небольшой скрипт, который создает файл при первом запуске и запускается только в том случае, если файл отсутствует? поэтому cron может вызывать скрипт 2x, но скрипт заметит, и логика выполняется только 1 раз. – aatdark 5 September 2010 в 03:33
  • 3
    Я вижу обходные пути, но я думаю, что мне нужен ответ на вопрос о том, как обрабатываются временные интервалы в cron. Я часто работаю над тем, что я не могу заставить работать, но я хотел бы также увеличить свое понимание. Комментарий +1 – Neil Trodden 5 September 2010 в 05:41

Вы можете попытаться переключить UTC = no , если это да или наоборот в / etc / default / rcS . Для этого запустите: 

  gksu gedit / etc / default / rcS
  • Измените UTC = no на UTC = yes , или
  • Изменить UTC = да до UTC = нет . [ ! d10]

Сохраните файл, закройте текстовый редактор и перезагрузите компьютер.

0
ответ дан 2 August 2018 в 04:31

Вы можете попытаться переключить UTC = no , если это да или наоборот в / etc / default / rcS . Для этого запустите: 

  gksu gedit / etc / default / rcS
  • Измените UTC = no на UTC = yes , или
  • Изменить UTC = да до UTC = нет . [ ! d10]

Сохраните файл, закройте текстовый редактор и перезагрузите компьютер.

0
ответ дан 4 August 2018 в 21:05

Вы можете попытаться переключить UTC = no , если это да или наоборот в / etc / default / rcS . Для этого запустите: 

  gksu gedit / etc / default / rcS
  • Измените UTC = no на UTC = yes , или
  • Изменить UTC = да до UTC = нет . [ ! d10]

Сохраните файл, закройте текстовый редактор и перезагрузите компьютер.

0
ответ дан 6 August 2018 в 04:36

Вы можете попытаться переключить UTC = no , если это да или наоборот в / etc / default / rcS . Для этого запустите: 

  gksu gedit / etc / default / rcS
  • Измените UTC = no на UTC = yes , или
  • Изменить UTC = да до UTC = нет . [ ! d10]

Сохраните файл, закройте текстовый редактор и перезагрузите компьютер.

0
ответ дан 7 August 2018 в 22:46

Вы можете попытаться переключить UTC = no , если это да или наоборот в / etc / default / rcS . Для этого запустите: 

  gksu gedit / etc / default / rcS
  • Измените UTC = no на UTC = yes , или
  • Изменить UTC = да до UTC = нет . [ ! d10]

Сохраните файл, закройте текстовый редактор и перезагрузите компьютер.

0
ответ дан 10 August 2018 в 10:51

Вы можете попытаться переключить UTC = no , если это да или наоборот в / etc / default / rcS . Для этого запустите: 

  gksu gedit / etc / default / rcS
  • Измените UTC = no на UTC = yes , или
  • Изменить UTC = да до UTC = нет . [ ! d10]

Сохраните файл, закройте текстовый редактор и перезагрузите компьютер.

0
ответ дан 13 August 2018 в 17:26
  • 1
    Не могу этого сделать! В самом худшем случае мой сценарий для обновления базы данных веб-форумов, чтобы переключить всех на летнее время (т. Е. Показывать UTC, а не UTC + 1), будет выполняться в 2 часа ночи, а затем снова (поскольку я установил часы назад на 1 утра). Альтернативой является то, что она не запускается, так как ОС может мгновенно вернуться к 1:00, а мое обновление работает через час. Я не хочу перезагружаться, и я, конечно, не хочу рисковать перезагрузкой дважды. Мне просто нужно определить, как ОС будет интерпретировать время моего хронометра, учитывая, что сервер также переключает BST! – Neil Trodden 5 September 2010 в 03:16
  • 2
    почему бы не создать небольшой скрипт, который создает файл при первом запуске и запускается только в том случае, если файл отсутствует? поэтому cron может вызывать скрипт 2x, но скрипт заметит, и логика выполняется только 1 раз. – aatdark 5 September 2010 в 03:33
  • 3
    Я вижу обходные пути, но я думаю, что мне нужен ответ на вопрос о том, как обрабатываются временные интервалы в cron. Я часто работаю над тем, что я не могу заставить работать, но я хотел бы также увеличить свое понимание. Комментарий +1 – Neil Trodden 5 September 2010 в 05:41

Другие вопросы по тегам:

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