У меня возникла проблема с RHEL 5.3 после попытки установить Perl Power Tools. Все работало нормально, пока я не попытался установить этот пакет вручную (у сервера нет доступа к Интернету).
Сначала каждый сценарий оболочки, использующий awk, выдавал ошибки, поэтому я удалил Perl Power Tools и переустановил awk из локального репозитория, настроенного на сервере, и эта проблема была решена. После этого задания cron начали выдавать ошибки с датой команды.
Когда я провожу "мужское свидание", это выходит:
DATE(1) User Contributed Perl Documentation DATE(1)
Name: date Description: display or set date and time Author: Joshua Gross License:
NAME
date - display or set date and time
perl v5.8.8 2014-12-18 DATE(1)
(END)
Но команда даты по умолчанию должна дать другой вывод:
DATE(1) User Commands DATE(1)
NAME
date - print or set the system date and time
SYNOPSIS
date [OPTION]... [+FORMAT]
date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]]
DESCRIPTION
Display the current time in the given FORMAT, or set the system date.
-d, --date=STRING
display time described by STRING, not ‘now’
-f, --file=DATEFILE
like --date once for each line of DATEFILE
-r, --reference=FILE
display the last modification time of FILE
-R, --rfc-2822
output date and time in RFC 2822 format
--rfc-3339=TIMESPEC
output date and time in RFC 3339 format. TIMESPEC=‘date’, ‘seconds’, or ‘ns’ for date and time to the
indicated precision.
-s, --set=STRING
set time described by STRING
-u, --utc, --universal
print or set Coordinated Universal Time
--help display this help and exit
Я попытался удалить дату и переустановить coreutils (пакет, содержащий дату), но по какой-то причине команда new date продолжает возвращаться. Я не знаю, как восстановить старую команду даты. Заранее спасибо.
Привет,
ОБНОВЛЕНИЕ1:
Вот как дата используется внутри скриптов и выдает ошибку:
date --date="1 days ago" +%Y%m
Option -date not support in this version.
Когда я пробую это на другом сервере с командой даты по умолчанию, он работает нормально.
Это результат того, какая дата:
[root@wrongserver ~]# which date
/bin/date
ОБНОВЛЕНИЕ 2:
Вывод даты - версия на обычном сервере:
[root@OKserver lib64]$ date --version
date (GNU coreutils) 5.97
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.
Written by David MacKenzie.
Вывод даты --версия на проблемном сервере:
[root@wrongserver ~]# date --version
date (GNU coreutils) 5.97
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.
Written by David MacKenzie.
Похоже, единственное, что не изменилось после переустановки, была страница руководства, и я фактически использую те же двоичные файлы даты, также дата поступает из правильного пакета
[root@domstats ~]# rpm -qf /bin/date
coreutils-5.97-19.el5
Но я все еще получаю ошибки, когда запускаю команду date в сценариях с помощью crontab, думаю, я не заметил этого достаточно раньше. Ошибка с командой date появляется ТОЛЬКО при строке date --date="1 days ago" +%Y%m запускается в скрипте с crontab. Если я запускаю строку в приглашении, все идет нормально. Если я запускаю сценарий вручную, он также работает.
Я сделал несколько тестов и изменил порядок, подобный этому, чтобы скрипты нормально работали с cron date +%Y%m --date="1 days ago"Конечно, изменение этого параметра в сценариях, которые у меня есть в cron, - это боль, и он должен работать нормально, поскольку на другом сервере работает.
Хорошо, я нашел эту маленькую ошибку, я знал, что это было что-то достаточно маленькое, чтобы не заметить. Оказывается, переменная PATH была изменена, когда скрипты в cron были запущены, и закончились так /usr/bin:/bin.
Конфликтующие date команда была установлена в / usr / bin, а не в / bin, поэтому cron использовал неправильный, и я не мог заметить, потому что в обычном сеансе пользователя переменная PATH была перевернута /bin:/usr/bin.
Спасибо за помощь.