Como uso o comando nohup sem obter o nohup.out?

Estou com um problema com o comando nohup.

Quando executo meu trabalho, tenho muitos dados. A saída nohup.out se torna muito grande e meu processo fica mais lento. Como posso executar este comando sem obter nohup.out?

O nohupcomando grava apenas nohup.outse a saída for para o terminal. Se você redirecionou a saída do comando para outro lugar - incluindo /dev/null- é para onde vai.

 nohup command >/dev/null 2>&1   # doesn't create nohup.out

Se você estiver usando nohup, isso provavelmente significa que você deseja executar o comando em segundo plano, colocando outro &no final de tudo:

 nohup command >/dev/null 2>&1 & # runs in background, still doesn't create nohup.out

No Linux, a execução de um trabalho com nohupfecha automaticamente sua entrada também. Em outros sistemas, principalmente no BSD e no macOS, esse não é o caso. Portanto, ao executar em segundo plano, você pode fechar a entrada manualmente. Embora o fechamento da entrada não tenha efeito na criação ou não nohup.outdela, evita outro problema: se um processo em segundo plano tentar ler algo da entrada padrão, ele será pausado, esperando que você a traga de volta ao primeiro plano e digite alguma coisa. Portanto, a versão extra segura é assim:

nohup command </dev/null >/dev/null 2>&1 & # completely detached from terminal 

Observe, no entanto, que isso não impede que o comando acesse o terminal diretamente, nem o remove do grupo de processos do seu shell. Se você deseja fazer o último e está executando bash, ksh ou zsh, pode fazê-lo executando disownsem argumento como o próximo comando. Isso significa que o processo em segundo plano não está mais associado a um "trabalho" do shell e não terá nenhum sinal encaminhado a ele pelo shell. (Observe a distinção: um disownprocesso ed não recebe sinais enviados automaticamente pelo shell pai - mas sem nohupele ainda receberá um HUPsinal enviado por outros meios, como um killcomando manual . Um nohupprocesso ignorado todos e quaisquer HUPsinais, não importa como eles são enviados.)

Explicação:

Nos sistemas Unixy, toda fonte de entrada ou destino de saída tem um número associado a ele chamado "descritor de arquivo" ou "fd", abreviado. Todo programa em execução ("processo") possui seu próprio conjunto e, quando um novo processo é iniciado, ele já possui três deles abertos: "entrada padrão", que é fd 0, é aberta para leitura do processo, enquanto "saída padrão" (fd 1) e "erro padrão" (fd 2) estão abertas para gravação. Se você acabou de executar um comando em uma janela de terminal, por padrão, qualquer coisa digitada vai para a entrada padrão, enquanto a saída padrão e o erro padrão são enviados para essa janela.

Mas você pode solicitar que o shell mude para onde um ou todos esses descritores de arquivo apontam antes de iniciar o comando; isso é o que o redirecionamento ( <, <<, >, >>) e tubo ( |operadores) fazer.

O tubo é o mais simples deles ... command1 | command2organiza a saída padrão command1para alimentar diretamente a entrada padrão de command2. Esse é um arranjo muito útil que levou a um padrão de design específico nas ferramentas UNIX (e explica a existência de erro padrão, que permite que um programa envie mensagens ao usuário mesmo que sua saída esteja indo para o próximo programa no pipeline) . Mas você só pode canalizar a saída padrão para a entrada padrão; você não pode enviar outros descritores de arquivo para um canal sem fazer malabarismos.

Os operadores de redirecionamento são mais amigáveis, pois permitem especificar qual descritor de arquivo redirecionar. Então 0<infilelê a entrada padrão do arquivo chamado infile, enquanto 2>>logfileacrescenta erro padrão para o final do arquivo chamado logfile. Se você não especificar um número, insira o padrão de redirecionamento para fd 0 ( <é o mesmo que 0<), enquanto o redirecionamento de saída será o padrão para fd 1 ( >é o mesmo que 1>).

Além disso, você pode combinar os descritores de arquivos: 2>&1significa "enviar erro padrão para onde a saída padrão estiver indo". Isso significa que você obtém um único fluxo de saída que inclui a saída padrão e o erro padrão misturados, sem mais nenhuma maneira de separá-los, mas também significa que você pode incluir o erro padrão em um pipe.

Portanto, a sequência >/dev/null 2>&1significa "enviar a saída padrão para /dev/null" (que é um dispositivo especial que simplesmente joga fora o que você escreve) "e, em seguida, envia um erro padrão para onde quer que a saída padrão esteja indo" (o que nós garantimos que era /dev/null). Basicamente, "jogue fora o que esse comando gravar no descritor de arquivo".

Quando nohupdetecta que nem o erro padrão nem a saída estão conectados a um terminal, ele não se preocupa em criar nohup.out, mas assume que a saída já está redirecionada para onde o usuário deseja.

O /dev/nulldispositivo também funciona para entrada; se você executar um comando </dev/null, qualquer tentativa desse comando de ler da entrada padrão encontrará instantaneamente o final do arquivo. Observe que a sintaxe de mesclagem não terá o mesmo efeito aqui; funciona apenas para apontar um descritor de arquivo para outro aberto na mesma direção (entrada ou saída). O shell permitirá que você faça isso >/dev/null <&1, mas isso acaba criando um processo com um descritor de arquivo de entrada aberto em um fluxo de saída; portanto, em vez de apenas atingir o final do arquivo, qualquer tentativa de leitura acionará um erro fatal "descritor de arquivo inválido".

nohup some_command > /dev/null 2>&1&

É tudo o que você precisa fazer!

Você já tentou redirecionar todos os três fluxos de E / S:

nohup ./yourprogram > foo.out 2> foo.err < /dev/null &

Você pode querer usar o programa de desanexação . Você o usa como ele, nohupmas ele não produz um log de saída, a menos que você o solicite. Aqui está a página do manual:

NAME
       detach - run a command after detaching from the terminal

SYNOPSIS
       detach [options] [--] command [args]

       Forks  a  new process, detaches is from the terminal, and executes com‐
       mand with the specified arguments.

OPTIONS
       detach recognizes a couple of options, which are discussed below.   The
       special  option -- is used to signal that the rest of the arguments are
       the command and args to be passed to it.

       -e file
              Connect file to the standard error of the command.

       -f     Run in the foreground (do not fork).

       -i file
              Connect file to the standard input of the command.

       -o file
              Connect file to the standard output of the command.

       -p file
              Write the pid of the detached process to file.

EXAMPLE
       detach xterm

       Start an xterm that will not be closed when the current shell exits.

AUTHOR
       detach was written by Robbert Haarman.  See  http://inglorion.net/  for
       contact information.

Nota: Não tenho afiliação com o autor do programa. Sou apenas um usuário satisfeito do programa.

O comando a seguir permitirá que você execute algo em segundo plano sem obter nohup.out:

nohup command |tee &

Dessa maneira, você poderá obter a saída do console enquanto executa o script no servidor remoto:

sudo bash -c "nohup /opt/viptel/viptel_bin/log.sh $* &> /dev/null"  &

Redirecionar a saída do sudo faz com que o sudo busque a senha, portanto, um mecanismo estranho é necessário para fazer essa variante.

Se você tem um shell BASH no seu mac / linux à sua frente, tente as etapas abaixo para entender praticamente o redirecionamento:

Crie um script de 2 linhas chamado zz.sh

#!/bin/bash
echo "Hello. This is a proper command"
junk_errorcommand

• A saída do comando echo entra no STDOUT filestream (descritor de arquivo 1).
• A saída do comando error entra no STDERR filestream (descritor de arquivo 2)

Atualmente, a simples execução do script envia STDOUT e STDERR para a tela.

./zz.sh

Agora comece com o redirecionamento padrão:

zz.sh > zfile.txt

No exemplo acima, "echo" (STDOUT) entra no zfile.txt. Enquanto "erro" (STDERR) é exibido na tela.

O acima é o mesmo que:

zz.sh 1> zfile.txt

Agora você pode tentar o contrário e redirecionar o "erro" STDERR para o arquivo. O comando STDOUT from "echo" vai para a tela.

zz.sh 2> zfile.txt

Combinando os dois acima, você obtém:

zz.sh 1> zfile.txt 2>&1

Explicação:

• PRIMEIRO, envie STDOUT 1 para zfile.txt
• ENTÃO, envie STDERR 2 para o próprio STDOUT 1 (usando & 1 ponteiro).
• Portanto, 1 e 2 entram no mesmo arquivo (zfile.txt)

Eventualmente, você pode compactar tudo dentro do comando nohup e executá-lo em segundo plano:

nohup zz.sh 1> zfile.txt 2>&1&

Você pode executar o comando abaixo.

nohup <your command> & >  <outputfile> 2>&1 &

por exemplo, eu tenho um comando nohup dentro do script

./Runjob.sh > sparkConcuurent.out 2>&1