Pourquoi voudriez-vous "cat / dev / null> / var / log / messages"?

Sur cette page d'exemple de script bash, l'auteur présente ce script:

# Cleanup
# Run as root, of course.

cd /var/log
cat /dev/null > messages
cat /dev/null > wtmp
echo "Log files cleaned up."

Pourquoi voudriez-vous cat /dev/nullsur quelque chose? Je n'arrive pas à comprendre ce qui est prévu ici (est-ce que c'est comme utiliser while TRUE; sleep 1; elihwpour {some busy program}?). Pourtant, l'auteur appelle cela «Rien d'inhabituel».

Vous devez généralement cat /dev/null > [something]effacer le contenu du fichier tout en évitant tout risque d'interruption de l'état du fichier. Le contenu du fichier sera clairement effacé par le cat /dev/nullfichier lui-même - tel qu'il existe et est connu du système de fichiers sur lequel il réside - sera toujours là avec le même numéro d'inode, la même propriété et les mêmes autorisations.

Dans le cas d'un fichier journal, il se peut que le fichier journal lui-même soit marqué «en cours d'utilisation» par un autre processus. Ce faisant, par exemple, rm /var/log/messages && touch /var/log/messagescela pourrait perturber d'autres processus et provoquer l'étouffement des processus en cours. Signifier qu'un processus qui est en quelque sorte verrouillé sur un numéro d'inode spécifique connecté au fichier /var/log/messagespourrait soudainement paniquer en disant: «Hé! Qu'est-il arrivé à /var/log/messages! ”Même si le fichier est toujours là. Sans parler des problèmes potentiels avec la propriété et les autorisations étant recréées de manière incorrecte.

En raison de cette incertitude dans l' utilisation / état d'un fichier de l'utilisation cat /dev/null > [something]est préféré par les administrateurs système qui veulent effacer un journal , mais ne veulent pas potentiellement interférer avec le fonctionnement des processus déjà existants.

De même, dans le contexte de la page que vous créez un lien avec l'auteur, vous indiquez ce qui suit:

Il n’ya rien d’inhabituel ici, seul un ensemble de commandes qui auraient tout aussi bien pu être invoquées une à une à partir de la ligne de commande de la console ou d’une fenêtre de terminal. Les avantages de placer les commandes dans un script vont bien au-delà du fait de ne pas avoir à les retaper encore et encore.

Donc, le «rien d’inhabituel» que l’auteur mentionne concerne tout le concept de ce script bash spécifique: c’est juste un ensemble de commandes simples qui peuvent tout aussi bien être exécutées à partir de la ligne de commande mais placées dans un fichier texte évitez de les retaper encore et encore.

Pourquoi voudriez-vous chat / dev / null sur quelque chose?

Vous ferez cela pour tronquer le contenu d'un fichier tout en conservant l'inode intact. Tous les programmes dont le fichier est ouvert en lecture ou en écriture ne seront pas affectés sauf que la taille du fichier sera remise à zéro.

Une alternative fausse souvent trouvée consiste à supprimer le fichier puis à le recréer:

rm file
touch file

ou similaire:

mv file file.old
gzip file.old
touch file

Le problème est que ces méthodes n’empêchent pas l’ancien fichier d’être conservé par tous les processus où le fichier supprimé est ouvert au moment de la suppression. La raison en est que, sous les systèmes de fichiers Unix, lorsque vous supprimez un fichier, vous ne faites que dissocier son nom (chemin) de son contenu (inode). L'inode est maintenu en vie tant qu'il existe des processus l'ayant ouvert en lecture ou en écriture.

Cela entraîne plusieurs effets négatifs: les journaux écrits après la suppression du fichier sont perdus car il n’existe aucun moyen simple / portable d’ouvrir un fichier supprimé. Tant qu'un processus écrit dans le fichier supprimé, son contenu utilise toujours de l'espace sur le système de fichiers. Cela signifie que si vous supprimez / créez le fichier parce qu'il remplissait votre disque, celui-ci reste rempli. Une façon de résoudre ce dernier problème consiste à redémarrer les processus du consignateur, mais vous pouvez ne pas le faire pour les services critiques et les journaux intermédiaires seraient définitivement perdus. Il existe également des effets secondaires dus au fait que le fichier que vous créez peut ne pas avoir les mêmes autorisations, propriétaire et groupe que celui d'origine. Cela pourrait, par exemple, empêcher un analyseur de journaux de lire le fichier nouvellement créé ou, pire, empêcher le processus de journalisation d'écrire ses propres journaux.

La première méthode permet d’ cat /dev/null > fileatteindre l’objectif correctement, mais malgré une légende urbaine tenace, sa cat /dev/nullpartie ne sert absolument à rien. Il ouvre un pseudo fichier qui est vide par conception, il ne lit rien et finit par se fermer. L'utilisation de cette commande est alors un gaspillage de frappes de touche, d'octets, d'appels système et de cycles de processeur et peut être remplacée sans aucune modification fonctionnelle par la commande no-op sans aucun doute plus rapide :ou même, avec la plupart des shells, par aucune commande.

Laissez-moi essayer une métaphore pour expliquer à quel point l'inutilité cat /dev/nullest inutile . Disons que votre objectif est de vider un verre.

• Vous en retirez d'abord tout liquide. C'est suffisant et c'est précisément ce que fait ( > file) étant donné que les redirections sont toujours traitées en premier.

• Ensuite, vous choisissez une bouteille vide ( /dev/null) et la versez dans le verre vide ( cat). C'est l'étape inutile

Si vous lisez votre document lié à la fin, vous remarquerez peut-être les commentaires dans cette ligne de la version améliorée du script:

    cat / dev / null> wtmp #   ':> wtmp' et '> wtmp' ont le même effet.

Ils ont en effet; tant pis a cat /dev/nullété conservé dans le code.

Cela signifie que le code suivant fonctionnera avec tous les shells courants (les deux cshet leurs shfamilles):

cd /var/log
: > messages
: > wtmp
echo "Log files cleaned up."

et cela fonctionnera avec toutes les coquilles en utilisant la syntaxe Bourne, comme ash, bash, ksh, zshet les goûts:

cd /var/log
> messages
> wtmp
echo "Log files cleaned up."

Notez cependant qu'avec les anciens shells Bourne pré-POSIX Bourne, aucune de ces commandes, y compris cat /dev/null, ne tronquera un fichier s'il est écrit ultérieurement par un script shell en cours d'exécution qui lui est ajouté. Au lieu d'un fichier de zéro octet, ce serait un fichier fragmenté dont la taille ne serait pas modifiée. La même chose se produirait si le fichier était écrit par un processus cherchant la position qu’il pensait être la précédente avant l’écriture.

Notez également que certaines solutions alternatives suggérées pour tronquer un fichier ont des défauts.

• Les deux suivants ne font tout simplement pas le travail. Le fichier résultant n'est pas vide mais contient une ligne vide. Cela romprait les fichiers journaux comme wtmpceux stockant des enregistrements de largeur fixe.

  echo > file
  echo "" > file

• La suivante basée sur une shoption BSD n'est pas portable, POSIX ne spécifie aucune option autorisée pour l'écho, vous pouvez donc vous retrouver avec un fichier contenant une ligne avec " -n":

  echo -n > file

• Celui-ci n'est pas portable non plus en utilisant une shséquence d'échappement System V. Certains shells vont créer un fichier contenant une ligne avec " \c":

  echo "\c" > file

• Celui-ci utilise une commande conçue pour faire le travail. Le problème n’est truncatepas portable car cette commande, qui n’a pas été spécifiée par POSIX, est peut-être absente d’un système Unix / Linux.

  truncate -s 0

Enfin, voici quelques solutions de rechange portables qui feront le travail correctement:

• Imprimer explicitement une chaîne vide dans le fichier:

  printf "" > file

• Utilisation de la truecommande strictement équivalente à la commande no-op :mais plus lisible:

  true > file

C'est un moyen fastidieux de ramener le fichier à une taille nulle.

cd /var/log
> messages
> wtmp
echo "Log files cleaned up."

Pour tronquer un fichier ouvert. Ceci est équivalent et plus compréhensible:

echo -n > /var/log/messages

(Ajouté -n pour éviter la nouvelle ligne)