Comment un programme de journalisation peut-il continuer à se connecter à un fichier supprimé?

Dans la section Unix Power Tools, 3e édition : au lieu de supprimer un fichier, videz -le:

Si un processus actif a le fichier ouvert (pas rare pour les fichiers journaux), la suppression du fichier et la création d'un nouveau n'affecteront pas le programme de journalisation; ces messages continueront simplement vers le fichier qui n'est plus lié . Vider le fichier ne rompt pas l'association et efface donc le fichier sans affecter le programme de journalisation.

(c'est moi qui souligne )

Je ne comprends pas pourquoi un programme continuera à se connecter à un fichier supprimé. Est-ce parce que l'entrée du descripteur de fichier n'est pas supprimée de la table de processus?

Lorsque vous supprimez un fichier, vous supprimez vraiment un lien vers le fichier (vers l'inode). Si quelqu'un a déjà ouvert ce fichier, il peut conserver le descripteur de fichier dont il dispose. Le fichier reste sur le disque, occupe de l'espace et peut être écrit et lu si vous y avez accès.

La unlinkfonction est définie avec ce comportement par POSIX:

Lorsque le nombre de liens du fichier devient 0 et qu'aucun processus n'a ouvert le fichier, l'espace occupé par le fichier doit être libéré et le fichier n'est plus accessible. Si un ou plusieurs processus ont le fichier ouvert lorsque le dernier lien est supprimé, le lien doit être supprimé avant le retour de unlink (), mais la suppression du contenu du fichier doit être différée jusqu'à ce que toutes les références au fichier soient fermées .

Ce conseil à cause de ce comportement. Le démon aura le fichier ouvert et ne remarquera pas qu'il a été supprimé (sauf s'il le surveillait spécifiquement, ce qui est rare). Il continuera à écrire allègrement dans le descripteur de fichier existant qu'il possède: vous continuerez à prendre (plus) d'espace sur le disque, mais vous ne pourrez voir aucun des messages qu'il écrit, donc vous êtes vraiment dans le pire des deux mondes. Si vous tronquez le fichier à une longueur nulle à la place, l'espace est libéré immédiatement et tous les nouveaux messages seront ajoutés à la nouvelle fin du fichier où vous pourrez les voir.

Finalement, lorsque le démon se termine ou closes le fichier , l'espace sera libéré. Personne de nouveau ne peut ouvrir le fichier entre-temps (sauf via des interfaces réfléchissantes spécifiques au système comme Linux/proc/x/fd/... ). Il est également garanti que:

Si le nombre de liens du fichier est de 0, lorsque tous les descripteurs de fichiers associés au fichier sont fermés, l'espace occupé par le fichier doit être libéré et le fichier ne doit plus être accessible.

Vous ne perdez donc pas votre espace disque de façon permanente, mais vous ne gagnez rien en supprimant le fichier et vous perdez l'accès aux nouveaux messages.

Exactement.

Les fichiers sont tripartites.

• Le contenu, c'est-à-dire un tableau plat d'octets, écrit quelque part sur un disque ou généré à la volée.
• Le nœud d'index , ou inode pour faire court, qui est une structure de données remplie et utilisée par le noyau. Il contient toutes les métadonnées (taille, autorisation, etc.) concernant le fichier et indique également l'emplacement du contenu du fichier.
• Une ou plusieurs entrées de répertoire , qui sont des emplacements, manipulées comme des chemins comme /home/user/personal_file, qui agissent comme des poignées à travers lequel vous pouvez utiliser le fichier, modifier son contenu, modifier ses métadonnées, etc.

Lorsque vous ouvrez un fichier, vous donnez le chemin d'accès au système d'exploitation et il vous renvoie un handle directement vers l'inode. Avec cette poignée, appelée descripteur de fichier, vous pouvez manipuler le fichier comme vous le souhaitez (ou au moins, comme le permet le système d'exploitation).

Vous ne pouvez jamais supprimer directement un inode, vous devez donner un chemin vers le système d'exploitation pour exiger la suppression. Ainsi, lorsque vous souhaitez supprimer un fichier, vous supprimez uniquement l'entrée de répertoire. Si le fichier a d'autres entrées de répertoire, il continuera à être accessible, et même s'il ne l'a pas, son inode ne sera pas supprimé tant qu'il y aura encore des descripteurs de fichier pointant vers lui. @ La réponse de MichaelHomer est plus technique et plus détaillée sur ce sujet spécifique.

Les 2 autres réponses expliquent bien le problème - un fichier n'est pas "supprimé" jusqu'à ce que tous les liens du répertoire vers lui et tous les descripteurs de fichiers ouverts soient partis.

Pour éviter cela, c'est une bonne habitude à utiliser

> /var/log/bigfile

au lieu de

rm -f /var/log/bigfile

car cela réinitialise simplement le contenu à 0 octet au lieu de le supprimer, et vous pouvez toujours voir ce qui y est écrit.

Si vous avez supprimé le fichier et que vous êtes sous Linux où vous avez un système de fichiers / proc / fd, vous pouvez toujours utiliser

> /proc/12345/fd/3

pour mettre à zéro le contenu du fichier (en supposant que 12345 est votre identifiant de processus et 3 est le numéro fd du gros fichier). Cela peut vous sauver la vie si votre disque est plein et que vous ne pouvez pas tuer le processus qui écrit votre fichier journal pour une raison quelconque.