Supprimer les premières N lignes d'un fichier journal actif
Existe-t-il un moyen de supprimer les premières lignes N d'un journal activement ajouté par une application?
Non, les systèmes d'exploitation comme Linux, et ses systèmes de fichiers, ne permettent pas de supprimer les données du début d'un fichier. En d'autres termes, le point de départ du stockage d'un fichier est corrigé.
Pour supprimer des lignes au début d'un fichier, vous devez généralement écrire les données restantes dans un nouveau fichier et en supprimer l'ancien. Si un ancien fichier est ouvert en écriture pour un programme, sa suppression est différée jusqu'à ce que l'application ferme le fichier.
Comme les commentateurs l'ont noté, pour les raisons évoquées dans la phrase précédente, vous devez généralement coordonner l'élagage du fichier journal avec les programmes qui écrivent les journaux. Cela dépend exactement des programmes. Certains programmes vont fermer et rouvrir leurs fichiers journaux lorsque vous leur envoyez un signal (par exemple, HUP), ce qui peut être utilisé pour empêcher que les enregistrements de journaux ne soient écrits dans un fichier journal "supprimé", sans interrompre le service.
Il existe de nombreux utilitaires disponibles pour gérer la taille des fichiers journaux, par exemple logrotate
Certains programmes ont leurs propres utilitaires. Par exemple, le serveur Web Apache comprend un utilitaire rotatelogs .
Je pense que cette tâche peut être accomplie avec sed
sed -i '1,10d' myfile
supprimerait les lignes de 1st au 10th ligne forme le fichier.
Je pense que tout le monde devrait au moins regarder ce sed 1 liners .
Notez que cela ne fonctionne pas pour les fichiers journaux auxquels une application ajoute activement (comme indiqué dans la question).
sed -i créera un nouveau fichier et "supprimera" le fichier sur lequel vous écrivez. La plupart des applications continueront à écrire des enregistrements de journal dans le fichier journal supprimé et continueront à remplir l'espace disque. Le nouveau fichier journal tronqué ne sera pas ajouté. Cela ne cessera que lorsque l'application est redémarrée ou est autrement signalée à fermer et à rouvrir ses fichiers journaux. À ce stade, il y aura un espace (enregistrements de journal manquants) dans le nouveau fichier journal s'il y a eu une activité pouvant être journalisée entre l'utilisation de sed et le redémarrage de l'application.
Un moyen sûr de procéder consiste à arrêter l'application, à utiliser sed pour tronquer le journal, puis à redémarrer l'application. Cette approche peut être inacceptable pour certains services (par exemple, un serveur Web avec des exigences de débit et de continuité de service élevées).
Non. Une solution à ce problème générique de croissance du fichier journal est la rotation du journal. Cela implique le déplacement régulier (généralement nocturne) d'un fichier journal existant vers un autre nom de fichier et un nouveau fichier journal vierge. Après une période, les anciens fichiers journaux sont jetés.
Voir: http://www-uxsup.csx.cam.ac.uk/~jw35/courses/Apache/html/x1670.htm
Ceci est une réponse , pas une solution. Il n'y a AUCUNE solution à la question. Le demandeur indique clairement: "à partir d'un journal en cours ajouté activement par une application". Vous pouvez lire pour en savoir plus et passer à la fin pour une suggestion que je formule en fonction de ma présomption sur la raison pour laquelle ce code ne suit pas les meilleures pratiques de journalisation.
Pour être clair: d’autres "réponses" proposent ici la fausse promesse . Aucune modification du nom ne trompera l'application en utilisant le nouveau fichier. Les informations les plus utiles se trouvent dans les commentaires sur ces réponses incorrectes.
Les fichiers ACTIF ne sont pas une sorte de conteneur dans lequel vous mettez simplement des données. Un nom de fichier pointe vers UN INODE (début du fichier) et chaque inode a un pointeur sur un autre Inode (s'il y a plus de données). Cela signifie qu'un fichier continu d'écriture a un flux constant d'inodes ajouté, et ce que vous pensez d'un "fichier" est en réalité une séquence de log d'inodes.
Imaginez que vous suiviez quelqu'un sur Google Maps et que cette personne puisse se téléporter n'importe où dans le monde, à tout moment, et que vous tentiez de relier ces points.
L'outil Linux "tronquer" peut supprimer les données à la fin du fichier, en parcourant simplement l'arborescence d'inodes et (à l'emplacement/à la taille que vous indiquez), il supprimera tous les pointeurs ultérieurs de la pile. Faire l'inverse - supprimer les données au début du fichier - serait un processus aussi horriblement complexe et risqué pour la réécriture de l'arborescence d'inodes en temps réel que personne n'écrira de tels outils pour le public, car ils échoueraient souvent et entraîneraient une perte de données. Le wiki Inodes est court mais explique certains de ces concepts.
** Mon conseil: retournez ce problème - POURQUOI cette application se comporte-t-elle de cette façon? Il existe de nombreuses meilleures pratiques de journalisation, mais elles sont souvent liées à la nature de votre système de journalisation (syslog, etc.). En principe, une application est censée "libérer" son traitement dans le fichier, afin que logrotate (etc.) puisse gérer le traitement ultérieur des anciennes données.
Chaque fois que j'entends "dans un fichier journal ACTIVE", je demande immédiatement à cette personne de me raconter "l'histoire spéciale" de cette application. Habituellement, c’est "le développeur a quitté, et nous ne pouvons pas changer le code. C’est en fait l’inverse de la sécurité, il a ses propres risques. Mais je vous demande une solution qui évite de toucher au code source. Si c’est le Dans ce cas, une question plus spécifique est nécessaire.