Comment utiliser la commande Nohup sans obtenir Nohup.out?
J'ai un problème avec la commande Nohup.
Quand je travaille, j'ai beaucoup de données. La sortie Nohup.out devient trop volumineuse et mon processus ralentit. Comment puis-je exécuter cette commande sans obtenir Nohup.out?
Nohup écrit uniquement dans Nohup.out si la sortie est destinée au terminal. Si vous redirigez la sortie de la commande ailleurs - y compris /dev/null -, c'est là que cela se passe.
Nohup command >/dev/null 2>&1 # doesn't create Nohup.out
Si vous utilisez Nohup, cela signifie probablement que vous souhaitez exécuter la commande en arrière-plan en plaçant un autre & à la fin de la tâche:
Nohup command >/dev/null 2>&1 & # runs in background, still doesn't create Nohup.out
Sous Linux, l'exécution d'un travail avec Nohup ferme également automatiquement son entrée. Sur d'autres systèmes, notamment BSD et macOS, ce n'est pas le cas. Par conséquent, lors de l'exécution en arrière-plan, vous souhaiterez peut-être fermer manuellement les entrées. Bien que la fermeture de l'entrée n'ait aucun effet sur la création ou non de Nohup.out, cela évite un autre problème: si un processus en arrière-plan essaie de lire quelque chose à partir d'une entrée standard, il s'interrompra en attendant que vous le renvoyiez au premier plan et que vous tapiez quelque chose. Donc, la version extra-sûre ressemble à ceci:
Nohup command </dev/null >/dev/null 2>&1 & # completely detached from terminal
Notez cependant que cela n'empêche pas la commande d'accéder directement au terminal, ni ne le supprime du groupe de processus de votre shell. Si vous souhaitez effectuer cette dernière opération et que vous exécutez bash, ksh ou zsh, vous pouvez le faire en exécutant disown sans argument en tant que commande suivante. Cela signifie que le processus d'arrière-plan n'est plus associé à un "travail" de Shell et qu'aucun signal ne lui sera transmis à partir du Shell. (Notez la distinction: un processus disowned ne reçoit aucun signal qui lui soit transmis automatiquement par son Shell parent - mais sans Nohup, il se fermera quand il recevra un signal HUP envoyé par d'autres moyens, comme une commande manuelle kill. Un processus Nohup 'ed ignore tous les signaux HUP, peu importe la façon dont ils sont envoyés.)
Explication:
Dans les systèmes Unixy, chaque source d'entrée ou cible de sortie est associée à un numéro appelé "descripteur de fichier" ou "fd". Chaque programme en cours ("processus") en possède son propre ensemble, et quand un nouveau processus démarre, il en a trois déjà ouverts: "entrée standard", qui est fd 0, est ouvert pour la lecture par le processus, tandis que "sortie standard" (fd 1) et "erreur standard" (fd 2) sont ouverts pour l'écriture. Si vous exécutez simplement une commande dans une fenêtre de terminal, tout ce que vous tapez est automatiquement affecté à son entrée standard, tandis que sa sortie standard et son erreur standard sont envoyées dans cette fenêtre.
Mais vous pouvez demander au shell de modifier l'emplacement de tout ou partie de ces descripteurs de fichier avant de lancer la commande; c'est ce que font les opérateurs redirection (<, <<, >, >>) et pipe (|).
Le tube est le plus simple de ceux-ci ... command1 | command2 permet à la sortie standard de command1 de s’alimenter directement dans l’entrée standard de command2. C'est un arrangement très pratique qui a conduit à un modèle de conception particulier dans les outils UNIX (et explique l'existence d'une erreur standard, ce qui permet à un programme d'envoyer des messages à l'utilisateur même si sa sortie est en train de passer au prochain programme en cours). . Mais vous pouvez uniquement diriger la sortie standard vers l'entrée standard. vous ne pouvez pas envoyer d'autres descripteurs de fichier à un canal sans jongler.
Les opérateurs de redirection sont plus conviviaux car ils vous permettent de spécifier le descripteur de fichier à rediriger. Donc, 0<infile lit l'entrée standard à partir du fichier nommé infile, tandis que 2>>logfile ajoute l'erreur standard à la fin du fichier nommé logfile. Si vous ne spécifiez pas de nombre, la redirection d'entrée par défaut est fd 0 (< est identique à 0<), tandis que la redirection de sortie par défaut est fd 1 (> est identique à 1>).
En outre, vous pouvez combiner des descripteurs de fichier: 2>&1 signifie "envoyer une erreur standard chaque fois que la sortie standard est utilisée". Cela signifie que vous obtenez un seul flux de sortie comprenant à la fois une sortie standard et une erreur standard, sans aucun moyen de les séparer. Cela signifie également que vous pouvez inclure une erreur standard dans un canal.
Donc, la séquence >/dev/null 2>&1 signifie "envoyer la sortie standard à /dev/null" (un périphérique spécial qui jette tout ce que vous écrivez), puis envoyer une erreur standard à l'endroit où la sortie standard se dirige "(nous nous sommes assurés que c'était /dev/null) . En gros, "élimine tout ce que cette commande écrit dans l'un ou l'autre des descripteurs de fichier".
Lorsque Nohup détecte que ni son erreur standard ni la sortie ne sont attachées à un terminal, la création de Nohup.out n'est pas gênante, mais suppose que la sortie est déjà redirigée à l'endroit souhaité par l'utilisateur.
Le périphérique /dev/null fonctionne également pour la saisie; Si vous exécutez une commande avec </dev/null, toute tentative de lecture de cette commande à partir de l'entrée standard rencontrera instantanément la fin du fichier. Notez que la syntaxe de fusion n'aura pas le même effet ici; cela ne fonctionne que pour pointer un descripteur de fichier sur un autre qui est ouvert dans le même sens (entrée ou sortie). Le shell vous laissera faire >/dev/null <&1, mais cela finira par créer un processus avec un descripteur de fichier d'entrée ouvert sur un flux de sortie. Ainsi, au lieu de frapper simplement la fin du fichier, toute tentative de lecture déclenchera une erreur fatale "descripteur de fichier invalide" .
Nohup some_command > /dev/null 2>&1&
C'est tout ce que vous devez faire!
Avez-vous essayé de rediriger les trois flux d'E/S:
Nohup ./yourprogram > foo.out 2> foo.err < /dev/null &
Vous voudrez peut-être utiliser le programme detach programme . Vous l'utilisez comme Nohup mais il ne génère pas de journal de sortie à moins que vous ne le lui indiquiez. Voici la page de manuel:
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.
Remarque Je n'ai aucune affiliation avec l'auteur du programme. Je ne suis qu'un utilisateur satisfait du programme.
La commande suivante vous permettra d’exécuter quelque chose en arrière-plan sans obtenir Nohup.out:
Nohup command |tee &
De cette façon, vous pourrez obtenir une sortie de la console tout en exécutant un script sur le serveur distant: 
Sudo bash -c "Nohup /opt/viptel/viptel_bin/log.sh $* &> /dev/null" &
La redirection de la sortie de Sudo oblige Sudo à demander le mot de passe. Un mécanisme compliqué est donc nécessaire pour exécuter cette variante.
vous pouvez faire ci-dessous Nohup &> 2> & 1 & Par exemple Je n'ai pas de commande hup dans le script. ./Runjob.sh> sparkConcuurent.out 2> & 1
Si vous avez un shell BASH sur votre mac/linux devant vous, essayez les étapes ci-dessous pour comprendre la redirection de manière pratique:
Créez un script de 2 lignes appelé zz.sh
#!/bin/bash
echo "Hello. This is a proper command"
junk_errorcommand
- La sortie de la commande echo passe dans STDOUT filestream (descripteur de fichier 1).
- La sortie de la commande d'erreur va dans STDERR filestream (descripteur de fichier 2)
Actuellement, la simple exécution du script envoie à la fois STDOUT et STDERR à l'écran.
./zz.sh
Commençons maintenant avec la redirection standard:
zz.sh > zfile.txt
Dans ce qui précède, "echo" (STDOUT) va dans le fichier zfile.txt. Alors que "erreur" (STDERR) est affiché à l'écran.
Ce qui précède est le même que:
zz.sh 1> zfile.txt
Vous pouvez maintenant essayer le contraire et rediriger "erreur" STDERR dans le fichier. La commande STDOUT from "echo" va à l'écran.
zz.sh 2> zfile.txt
En combinant les deux ci-dessus, vous obtenez:
zz.sh 1> zfile.txt 2>&1
Explication:
- EN PREMIER, envoyez STDOUT 1 dans zfile.txt
- ALORS, envoyez STDERR 2 à STDOUT 1 lui-même (en utilisant le pointeur & 1).
- Par conséquent, 1 et 2 vont dans le même fichier (zfile.txt)
Finalement, vous pouvez emballer le tout dans la commande Nohup & pour l'exécuter en arrière-plan:
Nohup zz.sh 1> zfile.txt 2>&1&