Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!212.27.60.64.MISMATCH!cleanfeed3-b.proxad.net!nnrp1-1.free.fr!not-for-mail
From: Thomas <fantome.forums.tDeContes@free.fr.invalid>
Newsgroups: fr.comp.os.unix
Mail-Copies-To: nobody
Subject: Re: =?UTF-8?Q?g=C3=A9rer?= des fichiers log
References: <fantome.forums.tDeContes-AD48E3.21414905072021@news.free.fr> <scubs2$u25$2@shakotay.alphanet.ch> <fantome.forums.tDeContes-F23835.20444917072021@news.free.fr> <sd0l91$b4m$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-130E7D.23050920072021@news.free.fr> <sd8faa$8ac$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-433B13.01575723072021@news.free.fr> <sddoan$flh$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-5442BA.19235419092021@news.free.fr> <si9urh$mad$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-D7C707.17401124092021@news.free.fr> <slrnsks8om.83t.sc@scarpet42p.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
Date: Sun, 26 Sep 2021 03:23:42 +0200
Message-ID: <fantome.forums.tDeContes-AD18A9.03233926092021@news.free.fr>
Lines: 117
Organization: Guest of ProXad - France
NNTP-Posting-Date: 26 Sep 2021 03:23:43 CEST
NNTP-Posting-Host: 91.175.52.121
X-Trace: 1632619423 news-4.free.fr 20284 91.175.52.121:7704
X-Complaints-To: abuse@proxad.net
Bytes: 6832

In article <slrnsks8om.83t.sc@scarpet42p.localdomain>,
 Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

> Le 24-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> 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.

pardon :
- j'ai pas précisé, je pensais ça en combinaison avec le fichier de 
config,
le wrapper script étant présent pour mettre à jour le fichier de config 
en cas de besoin.
- Marc ne m'a (finalement) pas suggéré de méthode pour passer le fichier 
de config sur la ligne de commande à mes conditions,
je suppose parce que le chercher à des emplacements définis lui 
convient, 
mais j'ai oublié que dans ce cas, si je veux que la XDG Base Directory 
Specification soit prise en charge, il faut que le logiciel gère 
lui-même au moins le morceau pour trouver le fichier de config
(après, pour les autres fichiers, ça peut passer uniquement par le 
fichier de config)


> 
> 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.

mon souci c'est que si qqn a juste des bugs à faire remonter, faut pas 
que ça soit trop compliqué.

c'est pas comme s'il lui prend simplement l'envie de regarder sous le 
capot. dans ce cas là c'est à lui de se remonter les manches.


> 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
(c'est rigolo, alors je rigole :-) )

> 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. 

aucun pb, en ada il suffit de rattraper toutes les exceptions.

la seule question qui me tracassait était de savoir dans quelle mesure 
ces erreurs là avaient besoin d'être rapportées à leur tour, parce qu'il 
y a un risque de tomber dans une boucle infinie.
mais si on n'a pas besoin de les rapporter, aucun pb :-)

> 
> 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.

tout ça me parait un peu compliqué (pour l'instant),

mais ce qui me parait simple c'est :
- de tout balancer sur stdout et stderr en plus des fichiers,
- qu'on puisse désactiver les fichiers si on les trouve encombrants, 
même si je veux qu'ils soient activés par defaut, comme ça on se 
retrouve dans le 1er cas.


> 
> 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.

j'aime bcp l'idée :-)

je ne sais pas si c'est facile à faire très rapidement, parce que :
- il faut que je définisse des règles pour catégoriser les logs
(auj dans mon code les logs ne sont divisés qu'en 2 catégories : DEBUG 
et ERROR)
- il faut que je réfléchisse à comment j'organise une ligne, pour que ça 
soit agréable à la fois
  - à utiliser en traitement automatique (c'était ça ton idée ?),
  - quand on l'affiche dans un terminal, en évitant de mettre des 
caracteres de contrôle qui vont fiche le bazar ...

est-ce que ça convient, d'avoir tous ces tags qui s'affichent dans le 
terminal quand on est en CLI (par ex au moment d'indiquer que les 
arguments sont mauvais) ?

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/