Eu tenho um script que sempre dá saída onde eu tenho ele redirecionado para um arquivo, o que eu estou tentando fazer é girar o arquivo redirecionado, abaixo é onde eu inicio o script e redireciono:
.
somecode
.
su - username -c "command >> /path/to/directory/output.txt" &
.
.
code continues..
e abaixo é o crontab que estou tentando criar:
cd /path/to/directory/
timestamp='date "+%Y%m%d"'
mv ./output.txt ./logs/output.txt_$timestamp
touch output.txt
chmod 757 ./output.txt
gzip ./logs/output.txt_$timestamp
find ./logs/output.txt* -type f -mtime +2 | xargs rm
ou este também não conseguiu fazer o trabalho:
timestamp='date "+%Y%m%d"'
cp ./output.txt ./logs/output.txt_$timestamp
echo "" > ./output.txt
gzip ./logs/output.txt_$timestamp
no primeiro código o script original falha e não está mais funcionando, e no segundo script ele não limpa o arquivo output.txt.
Existe uma maneira de fazer isso enquanto mantém o script funcionando? Nota; Estou executando o Unix Solaris.
Obrigado antecipadamente.
Isso geralmente é feito adicionando um manipulador SIGHUP que reinicia o comando após algum outro comando (normalmente logrotate ) moveu o arquivo. Nos sistemas operacionais * nix, você pode mover arquivos enquanto eles estão sendo gravados (acredito, com a ressalva de que ele ainda precisa estar no mesmo sistema de arquivos); as linhas extras serão anexadas ao arquivo no novo local.
Você realmente não pode alterar o stdout e / ou stderr de um processo em execução para um novo arquivo (veja a observação abaixo). Essa é uma das razões para usar arquivos de log stdout ou stderr como redirecionados. processos em execução é uma idéia ruim .
Quando o processo é iniciado, os elementos de redirecionamento do comando são executados pelo shell que inicia o processo. O arquivo de destino é aberto e criado, se necessário, no modo apropriado (anexado ou sobrescrito) e, possivelmente, truncado para zero bytes, dependendo do modo de redirecionamento. Em seguida, o descritor de arquivo aberto é passado para o processo filho. Esse descritor de arquivo aberto é o único link para o arquivo redirecionado que o processo filho possui - literalmente. É um link para o arquivo.
E esse é um ponto importante - como um link diretamente para o arquivo, o descritor aberto está no mesmo nível da entrada de diretório do arquivo - o "nome do arquivo". Alterar esse nome ou mesmo excluir essa entrada de diretório - como com o comando rm - não tem absolutamente nenhum efeito sobre o descritor de arquivo aberto no processo.
A resposta de @ l0b0 está correta de que processos que precisam rodar logs tendem a usar SIGHUP handlers para fazer tais rotações, mas "rotating logs" não é tão simples no caso de saída redirecionada - o que o novo arquivo de saída ser nomeado? O processo filho não tem idéia de qual é o "nome" de stdout e / ou stderr - e o "arquivo" de saída pode nem ser um arquivo em primeiro lugar.
Os esquemas de rotação de logs devem ser projetados no processo - o registro deve ser integrado de forma que as entradas de log não se percam no meio da rotação do arquivo de registro, por exemplo.
(OK, pode ser possível alterar os fluxos stdout / stderr de um processo em execução - mas é algo que tem que ser - novamente - projetado no processo. Não é algo que um binário pronto para usar, como bash fará automaticamente, se você enviar um SIGHUP ...)
Agradecemos muito a todos por suas respostas, não conseguimos encontrar uma maneira de fazer isso, então, como solução alternativa, eu configuro o crontab para parar o script original, fazer a rotação e iniciá-lo novamente no pico.
Tags bash cron solaris shell-script