{"id":4919,"date":"2017-05-01T05:00:20","date_gmt":"2017-05-01T04:00:20","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=4919"},"modified":"2017-06-05T03:19:38","modified_gmt":"2017-06-05T02:19:38","slug":"dailyfile-un-petit-outil-en-ligne-de-commande","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2017\/05\/01\/dailyfile-un-petit-outil-en-ligne-de-commande\/","title":{"rendered":"Dailyfile : un petit outil en ligne de commande"},"content":{"rendered":"

\"Dailyfile\"<\/a><\/p>\n

J’ai r\u00e9cemment \u00e9t\u00e9 confront\u00e9 \u00e0 un souci de taille de fichiers de traces pour le d\u00e9bogage d’une application. Pour r\u00e9soudre mon probl\u00e8me j’ai \u00e9crit un petit programme en ligne de commande permettant de r\u00e9partir la sortie d’un pipeline<\/em> du shell dans des fichiers quotidiens.<\/p>\n

J’ai appel\u00e9 cet outil dailyfile<\/strong><\/code> et je vous le pr\u00e9sente ici, en esp\u00e9rant qu’il puisse servir \u00e0 d’autres.<\/p>\n

\n\n<\/p>\n

Pr\u00e9sentation<\/h1>\n

Probl\u00e9matique<\/h2>\n

J’ai d\u00e9velopp\u00e9 il y a quelques temps pour un client un programme sous Linux qui s’occupe d’initialiser et de superviser des communications entre des applications distantes et des serveurs. La mise au point est un peu compliqu\u00e9e car les communications reposant sur des modems 2G des difficult\u00e9s inattendues apparaissent dans la gestion des d\u00e9connexions intempestives.<\/p>\n

J’ai pr\u00e9vu, comme d’habitude, dans mon programme de nombreux messages de d\u00e9bogage que l’on peut activer ou non en fonction d’un niveau param\u00e9trable \u00e0 la compilation.<\/p>\n

Un script d\u00e9marre l’application, qui \u00e9crira tous ses messages de d\u00e9bogage sur la sortie stderr<\/code>. Comme je n’ai pas acc\u00e8s directement \u00e0 ce serveur, les donn\u00e9es sont redirig\u00e9es dans un fichier que mon client me transmet par mail quand un probl\u00e8me survient. Le script est un peu plus complexe, mais on peut imaginer quelque chose comme\u00a0:<\/p>\n

$ .\/my-application >logfile.txt 2>&1<\/strong>\n<\/pre>\n
La premi\u00e8re redirection envoie la sortie standard stdout<\/code> du programme dans le fichier de trace, la seconde redirection 2>&1<\/code> redirige la sortie stderr<\/code> de la m\u00eame mani\u00e8re. Le script r\u00e9el est plus compliqu\u00e9 car on g\u00e8re un red\u00e9marrage automatique en cas de crash et un fichier de trace dont le nom contient la date de d\u00e9marrage.<\/p>\n
Les erreurs se produisant somme toute assez rarement, le programme tourne parfois pendant plusieurs jours entre deux red\u00e9marrages, et le fichier de trace p\u00e8se facilement plusieurs centaines de m\u00e9gaoctets. Son transfert et l’analyse de son contenu deviennent alors plus compliqu\u00e9s.<\/p>\n
On ne peut pas facilement r\u00e9partir le contenu dans diff\u00e9rents fichiers sans arr\u00eater l’application, ce qui est probl\u00e9matique dans notre cas. L’utilisation de logrotate<\/code> est un peu complexe, d’autant que nous n’avons pas les droits d’administration sur le serveur.<\/p>\n
Solution<\/h2>\n
Mon id\u00e9e a \u00e9t\u00e9 de remplacer la redirection \u00ab\u00a0><\/code>\u00a0\u00bb vers un fichier par une redirection \u00ab\u00a0|<\/code>\u00a0\u00bb dans un pipeline<\/em>. De l’autre c\u00f4t\u00e9 du pipeline<\/em> un programme lira les donn\u00e9es, et les copiera dans un fichier, en changeant tous les jours.<\/p>\n
La programmation proprement dite est simple, et le code source est disponible dans mon d\u00e9p\u00f4t Github<\/a>.<\/p>\n
Installation<\/h1>\n
La compilation du programme ne pr\u00e9sente en principe pas de difficult\u00e9\u00a0:<\/p>\n
$ git  clone  https:\/\/github.com\/cpb-\/Dailyfile<\/a><\/strong>\nClonage dans 'Dailyfile'...\nremote: Counting objects: 33, done.\nremote: Compressing objects: 100% (21\/21), done.\nremote: Total 33 (delta 12), reused 31 (delta 10), pack-reused 0\nD\u00e9paquetage des objets: 100% (33\/33), fait.\nV\u00e9rification de la connectivit\u00e9... fait.\n$ cd  dailyfile\/<\/strong>\n$ make clean  &&  make<\/strong>\nrm -f dailyfile dailyfile.o *~\ngcc -Wall -W -DPROGRAM_VERSION=\"0.3\" -c  dailyfile.c\ngcc -o dailyfile dailyfile.o \n$ sudo  make  install<\/strong>\ncp dailyfile \/usr\/local\/bin\/\n$<\/pre>\n
Utilisation<\/h1>\n
L’utilisation de base est plut\u00f4t simple\u00a0:<\/p>\n
$  commande-qui-dure-longtemps<\/em>  |  dailyfile<\/strong><\/pre>\n
Toutes les donn\u00e9es \u00e9crites par la premi\u00e8re commande dans le pipeline<\/em> seront enregistr\u00e9es dans des fichiers nomm\u00e9s day-YYYY-MM-DD.log<\/code> o\u00f9 YYYY<\/code>, MM<\/code>, et DD<\/code> repr\u00e9sentent respectivement l’ann\u00e9e, le mois et le jour de cr\u00e9ation du fichier.<\/p>\n
En voici un exemple d’ex\u00e9cution r\u00e9elle\u00a0:<\/p>\n
$ while true; do date; sleep 5; done | dailyfile<\/strong><\/pre>\n
Cette commande affiche la date toutes les cinq secondes. On retrouve plusieurs jours plus tard les r\u00e9sultats dans les fichiers\u00a0:<\/p>\n
$ ls -l<\/strong>\ntotal 2148\n-rw-r--r-- 1 cpb cpb 583906 avril 29 01:59 day-2017-04-28.log\n-rw-r--r-- 1 cpb cpb 727838 avril 30 01:59 day-2017-04-29.log\n-rw-r--r-- 1 cpb cpb 750812 mai    1 01:59 day-2017-04-30.log\n-rw-r--r-- 1 cpb cpb 113240 mai    1 06:08 day-2017-05-01.log\n<\/pre>\n
On peut remarquer que l’heure de la derni\u00e8re modification des fichiers \u00e9coul\u00e9s est \u00e0 1 heure 59. C’est normal, le basculement est effectu\u00e9 en se basant sur l’heure G.M.T, d\u00e9cal\u00e9e de deux heures l’\u00e9t\u00e9 par rapport \u00e0 l’heure locale affich\u00e9e par ls<\/code>.<\/p>\n
Options<\/h2>\n
Il existe quelques options pour modifier le comportement du programme.<\/p>\n