Surveille tes logs, ça pourrait revenir.
Comment ça se fait d’ailleurs?
En tout cas, encore merci à toi, bon dimanche!
Quel intérêt ?
Non ! On n’utilise pas un éditeur pour visualiser un fichier mais un programme de visualisation (“pager”) comme [mono]less[/mono], [mono]more[/mono], [mono]most[/mono]… voire [mono]head[/mono] ou [mono]tail[/mono] pour afficher juste le début ou la fin si le fichier est très gros.
[mono]fdisk -l[/mono] ne montre absolument rien de l’occupation des systèmes de fichiers. C’est la commande [mono]df -h[/mono] qu’il faut utiliser.
Si l’inondation continue, on doit la retrouver dans les fichiers de logs plus récents comme syslog.0 et syslog, messages.0 et messages.
Quel intérêt ?
[/quote]
Les fichiers log en particulier sont souvent ouvert depuis une application, si tu le supprimes directement, il disparaîtra de ton “ls” mais restera sur le disque. Alors même si un fichier log avec un suffixe log.x est censé être fermé, tu peux justement arrivé au moment ou il devient .x+1 (J’ai déjà rencontré le problème sur des tâches cron qui supprimaient les vieux logs)
Regarde le fil depuis le début, tu verras qu’il ne savait pas utiliser “cd”, et tu veux que je lui parle de tail ou même less ??
Et entre parenthèses j’épluche depuis 20 ans mes logs en environnement Unix avec “vi” et je n’ai jamais eu de problème, et je n’en changerai pas.
C’est ce que j’ai demandé.
[quote=“PascalHambourg”]
Si l’inondation continue, on doit la retrouver dans les fichiers de logs plus récents comme syslog.0 et syslog, messages.0 et messages.[/quote]
Voilà, c’est pas révolutionnaire, mais cette intervention peut éventuellement lui apporter quelque chose, ça aurait suffit.
Je veux, oui. Tu ne vas quand même pas soutenir que vi ou nano est plus facile à utiliser ? Je maintiens qu’ouvrir un énorme fichier avec un éditeur est une aberration qui aboutit au résultat observé : ça bloque.