Serveur Linux à court d'espace

31

On m'a posé cette question dans deux entretiens consécutifs, mais après quelques recherches et vérifications auprès de divers administrateurs systèmes, je n'ai pas reçu de bonne réponse. Je me demande si quelqu'un peut m'aider ici.

Un serveur manque d'espace disque. Vous remarquez un fichier journal très volumineux et déterminez qu'il peut être supprimé en toute sécurité. Vous supprimez le fichier mais le disque montre toujours qu'il est plein. Qu'est-ce qui pourrait causer cela et comment y remédier? Et comment trouveriez-vous quel processus écrit cet énorme fichier journal?

— ewwhite
source

3

Vous devez parler à de meilleurs administrateurs systèmes. C'est un truc insignifiant.

— womble

2

Trivial, mais la situation et la question

— reviennent

Le PO pourra-t-il l'accepter?

— ewwhite

5

Trivial ou non, pour quelqu'un qui ne parle pas couramment * nix (par exemple un administrateur principalement Windows), c'est une bonne chose à apprendre.

— John Gardeniers

56

Il s'agit d'une question d'entrevue courante et d'une situation qui survient dans divers environnements de production.

Les entrées du répertoire du fichier ont été supprimées, mais le processus de journalisation est toujours en cours. L'espace ne sera pas récupéré par le système d'exploitation tant que tous les descripteurs de fichiers n'auront pas été fermés (par exemple, le processus a été supprimé) et toutes les entrées de répertoire supprimées. Pour trouver le processus d'écriture dans le fichier, vous devrez utiliser la lsofcommande.

L'autre partie de la question peut parfois être «comment effacer un fichier en cours d'écriture sans tuer le processus? Idéalement, vous devez "zéro" ou "tronquer" le fichier journal avec quelque chose comme : > /var/log/logfileau lieu de supprimer le fichier.

— ewwhite
source

1

... ou fuser.

— Steven lundi

1

Expansion un peu: jusqu'à ce que toutes les références à un fichier sur le disque disparaissent, cet espace ne peut pas être utilisé par autre chose. Cela inclut les descripteurs de fichiers. Cela permet également à cette astuce de fonctionner: serverfault.com/questions/45237/link-to-a-specific-inode

— Jeff Ferland

1

Si vous vous êtes no-clobberfixé, essayez:>| /var/log/logfile

— Belmin Fernandez

2

Je pose une variante de cette question à chaque interview: "Vous recevez des messages de disque plein. dfDit que votre espace est insuffisant, dudit que vous en utilisez à peine.

— voretaq7

Que faire si après > /var/log/filel'espace sur le disque toujours à 100%? Le fichier journal semble être vide ... mais seulement après avoir redémarré le programme qui écrit sur ce fichier journal, l'espace est récupéré. Existe-t-il un moyen de récupérer l'espace disque sans redémarrer le programme?

— alemani

14

Il y a encore un autre lien vers le fichier (lien dur ou descripteur de fichier ouvert). La suppression d'un fichier supprime uniquement l'entrée du répertoire; les données du fichier et l'inode restent en attente jusqu'à ce que la dernière référence à celui-ci ait été supprimée.

Il est assez courant qu'un service crée un fichier temporaire et le supprime immédiatement tout en gardant le fichier ouvert. Cela crée un fichier sur le disque, mais garantit que le fichier sera supprimé si le processus se termine anormalement, et empêche également d'autres processus de piétiner accidentellement le fichier. MySQL le fait, par exemple, pour toutes ses tables temporaires sur disque. Les logiciels malveillants utilisent souvent des tactiques similaires pour masquer leurs fichiers.

Sous Linux, vous pouvez facilement accéder à ces fichiers supprimés en tant que /proc/<pid>/fd/<filenumber>.

— tylerl
source

8

Je ne suis pas un administrateur système, mais d'après ce que j'ai rassemblé sur Unix.SE, un système Linux ne supprimera pas réellement un fichier (marquez l'espace comme libre / réutilisable) après sa dissociation jusqu'à ce que tous les descripteurs de fichiers pointant vers eux aient été fermé. Donc pour répondre à la première partie, l'espace n'est pas encore libre car un processus le lit toujours. Pour répondre à la seconde, vous pouvez voir avec quel processus utilise le fichier lsof.

— Kevin
source

2

Une réponse alternative en plus de la réponse évidente de lien dur / fichier ouvert: ce fichier est un fichier (très) clairsemé comme /var/log/lastlogsur RHEL qui ne prenait pas vraiment beaucoup d'espace. La supprimer a eu très peu d'impact, vous devez donc regarder le prochain fichier le plus gros.

— Alexios
source

1

Si le processus d'écriture du fichier est root, il écrit dans l'espace fichier réservé au superutilisateur. Le système de fichiers dispose de cet espace pour garder un système opérationnel au cas où une tâche utilisateur remplit le disque. Cet espace (à mon humble avis par défaut 5%) est invisible pour de nombreux outils.

lsof peut vous montrer quel processus a verrouillé le fichier, ergo y écrit.

— Quelqu'un
source

1

Vous pouvez également ajuster ce pourcentage de réserve à l'aide de tune2fs. Cela peut être un moyen rapide de permettre au serveur de continuer à fonctionner pendant que vous libérez de l'espace disque.

— sjbotha

1

Outre le fichier ouvert par un processus, un deuxième cas est celui où vous avez un système de fichiers qui prend en charge les instantanés comme btrfsou ZFS.

Par exemple, vous prenez un instantané avec cet énorme fichier journal existant. Si vous supprimez le fichier maintenant, vous ne supprimerez que le delta. Et le delta est supprimé uniquement lorsque le fichier n'est pas utilisé.

Voir également:

Un troisième cas est celui où vous avez un système de fichiers qui prend en charge la déduplication au niveau du bloc et la plupart du fichier est identique à un autre fichier. Je ne m'attends pas à ce que cela se produise pour un journal, sauf si vous avez un conteneur ou une machine virtuelle qui envoie les journaux à un conteneur syslog ou à une machine virtuelle qui partagent le même FS afin que le contenu du journal soit identique.

— Mircea Vutcovici
source