Estou tendo um problema em um RHEL 5.3 depois de tentar instalar o Perl Power Tools. Tudo estava funcionando bem até que eu tentei instalar esse pacote manualmente (o servidor não tem acesso à internet).
No começo, todo script de shell que usava o awk estava dando erros, então eu removi o Perl Power Tools e reinstalei o awk de um repositório local que está configurado no servidor e esse problema foi resolvido. Depois que as tarefas cron começaram a dar erros com a data do comando.
Quando eu faço um "encontro de homem", isso está acontecendo:
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)
Mas o comando de data padrão deve fornecer essa outra saída:
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
Eu tentei desinstalar a data e reinstalar o coreutils (o pacote que contém a data), mas por alguma razão o novo comando date continua voltando. Eu não sei como restaurar o antigo comando de data. Agradecemos antecipadamente.
Felicidades,
UPDATE1:
É assim que a data está sendo usada dentro dos scripts e o erro que ela produz:
date --date="1 days ago" +%Y%m
Option -date not support in this version.
Quando eu tento isso em outro servidor com o comando de data padrão, ele roda bem.
Esta é a saída de qual data:
[root@wrongserver ~]# which date
/bin/date
UPDATE 2:
Saída da data --version no servidor normal:
[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.
Saída de data --version em servidor problemático:
[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.
Parece que a única coisa que não mudou depois da reinstalação foi a man page e estou realmente usando os mesmos binários de data, também a data está vindo do pacote certo
[root@domstats ~]# rpm -qf /bin/date
coreutils-5.97-19.el5
Mas ainda estou recebendo os erros quando executo o comando date em scripts usando o crontab, acho que não observei isso antes. O erro com o comando date vem APENAS quando a linha date --date="1 days ago" +%Y%m é executada em um script com crontab. Se eu executar a linha no prompt vai tudo bem, se eu executar o script manualmente também funciona.
Fiz alguns testes e alterando a ordem como esta fazem os scripts rodarem normalmente com o cron date +%Y%m --date="1 days ago" , claro, alterando isso nos scripts que tenho no cron é uma dor e ele deve funcionar normalmente já que no outro servidor faz trabalho.
Ok, eu achei esse pequeno bug, eu sabia que era algo pequeno o suficiente para não ser notado. Acontece que a variável PATH estava sendo alterada quando os scripts no cron foram executados e terminaram assim /usr/bin:/bin .
O comando conflitante date foi instalado em / usr / bin e não em / bin, então o cron estava usando o errado e eu não percebi porque na sessão normal do usuário a variável PATH foi invertida /bin:/usr/bin .
Obrigado pela ajuda.