Path: ...!news.misty.com!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!cleanfeed2-b.proxad.net!nnrp1-1.free.fr!not-for-mail Newsgroups: fr.comp.os.unix From: =?UTF-8?Q?St=C3=A9phane?= CARPENTIER Subject: Re: =?UTF-8?Q?g=C3=A9rer?= des fichiers log References: Organization: Mulots' Killer User-Agent: slrn/1.0.3 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-ID: Date: 24 Sep 2021 19:12:22 GMT Lines: 52 NNTP-Posting-Date: 24 Sep 2021 21:12:22 CEST NNTP-Posting-Host: 78.201.248.7 X-Trace: 1632510742 news-1.free.fr 3683 78.201.248.7:35934 X-Complaints-To: abuse@proxad.net Bytes: 4298 Le 24-09-2021, Thomas a écrit : > > mais au fait, peut être considères-tu que les applications ne devraient > juste pas essayer de s'en mêler, et que c'est aux intégrateurs de faire > l'interface via le wrapper script ? On y arrive. Soit tu ne veux voire les choses que d'un côté applicatif. Dans ce cas, c'est simple, tu balances tout sur stdout et stderr et tu laisses les intégrateurs, admins systèmes et utilisateurs finaux gérer ce qu'ils en font comme ils le veulent. Si les logs sont perdus lancés en mode graphique, c'est pas grave, l'utilisateur a toujours la possibilité de lancer en ligne de commande (même le mode graphique) pour voir les logs qui l'intéressent sur le terminal le jour où il veut comprendre. Si le packageur, l'administrateur ou l'utilisateur final considère que les logs sont importants, il est possible de gérer le lancement en redirigeant les logs dans un fichier. C'est pas forcément ton problème. Soit tu veux absolument, écrire des logs dans un fichier et ça commence à être de l'administration système. Et c'est là que ça commence à être rigolo. D'abord, il faut que quoiqu'il arrive, l'absence de possibilité d'écrire tes logs ne puisse pas empêcher ton appli de tourner. Ça veut dire que dans ton code tu dois prendre en compte une mauvaise installation ou un mauvais lancement. Ensuite, il y a le packager qui doit pouvoir choisir le répertoire de logs par défaut lors de l'installation. Puis, l'admin système doit pouvoir en choisir un autre pour l'ensemble de ses utilisateurs. Puis, un utilisateur particulier doit pouvoir choisir où il met les logs pour lui. Avec la possibilité de changer les logs par une option lors du démarrage s'il veut faire un test. C'est pour ça qu'il faut bien que tu fasses attention à la préséance dans le choix des possibilités si c'est défini à plusieurs endroits. Il faut absolument que ce qui est écrit en dur dans ton code ne soit utilisé que si rien d'autre n'est trouvé. Il faut aussi que l'option en ligne de commande prenne le dessus sur toutes les variables d'environnement et fichiers de conf. De même que l'utilisateur final peut écrire dans son $HOME et pas dans /etc et donc /etc va être réservé à l'admin système ou au packager et être moins prioritaire que $HOME. Pour la séparation de stdout et stderr, c'est pas forcément très utile. Il me semble préférable de tout mettre au même endroit avec un niveau de log qui contient un tag et qui est paramétrable. Par exemple, tu mets du DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un niveau d'activation faible en temps normal pour avoir moins de lignes et tu affiches tout quand tu veux comprendre ce qu'il se passe. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io