Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Unix gérer des fichiers log

gérer des fichiers log

78 réponses
Avatar
Thomas
bonjour :-)


j'ai des logs Í  gérer, et j'aimerais mieux ne pas les effacer quand j'ai
besoin de place pour un nouveau fichier.


j'ai regardé ce qui se passe dans /var/log/ :

est ce que c'est qqch de plus ou moins normalisé, ou est ce qu'on fait
vraiment ce qu'on veut ?


1
j'aime bcp l'idée d'avoir un n° que je peux incrementer jusqu'Í 
l'infini, pas de limite supérieure :-)


2
le gros pb, c'est que ça ajoute le n° après l'extension plutÍ´t qu'avant.
du coup, mon éditeur de texte croit avoir affaire Í  des pages de man
plutÍ´t qu'Í  des logs !

quel genre de pb ça peut poser si je décide de faire différemment ?

et pendant que j'y suis, pourquoi ne pas corriger ça au niveau du
système ?


3
apparemment, quand on a besoin de place, on décale tous les fichiers
d'un cran.

si Í  la place je met juste le dernier n° (le 1er dispo) au fichier qui
n'en a pas encore, sans toucher aux autres, qu'est ce que vous en dites ?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
4 5 6 7 8
Avatar
Thomas
In article <sipvq8$3u2$,
Marc SCHAEFER wrote:
Thomas wrote:
c'est que "ce n'est pas grave" de ne pas écrire de fichiers de log, même
si on a dit dans le fichier de config qu'on en voulait,
donc en cas de pb quelconque avec le fichier, je me contente de stderr
plus éventuellement dialogue GUI.

Me semble sensé.

je te remercie pour toute l'aide que tu m'as apportée, en ayant cette
bonne discussion sur ce qui est acceptable ou pas de part et d'autre :-)
et je te propose que ça soit le mot de la fin pour ce fil :-)
je remercie aussi tous ceux qui sont intervenus pour donner leur avis,
on a tjr besoin d'avis différents :-)
bien sur, je veux bien poursuivre un peu avec Stéphane CARPENTIER s'il
le souhaite, ou même avec d'autres s'il y en a qui veulent intervenir ou
poursuivre :-)
mais avec un bémol, c'est qu'avec Marc j'ai trouvé un équilibre qui nous
convient Í  tous les 2, et si qqn vient dire qu'il n'es pas d'accord, ça
risque de chambouler tous mes plans ...
mais ce bémol ne doit pas limiter votre liberté d'expression :-)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
Stéphane CARPENTIER
Le 27-09-2021, Thomas a écrit :
In article ,
Stéphane CARPENTIER wrote:
Il n'y a rien de compliqué. Si tu balances tous tes logs sur ta sortie
d'erreur, tu dis Í  l'utilisateur de tapper la commande
« $> monsuperprogramme 2> fichier.log »
et de t'envoyer le fichier « fichier.log » quand il a reproduit le bug.

et pour Windows,
je vais sur un forum Windows pour demander comment faire, et ensuite je
transmet Í  l'utilisateur la réponse qu'on me donne sans l'avoir
pratiquée.
ou alors je lui répond "vas sur un forum Windows pour demander comment
on fait ça, moi je sais pas".

Oui, bon, alors effectivement, Windows, je ne connais pas, je ne sais
pas comment ça marche et c'est pas mon problème. Mes réponses sont
orientées unix. Dans les grandes lignes ça doit pouvoir s'adapter sur
Windows mais je ne sais pas comment.
En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être
rapporté.

je crois qu'on s'est entendu avec Marc sur le fait qu'il n'y avait pas
de nécessité Í  cet endroit.
et si qqn d'autre me fais changer d'avis plus tard ... tant pis, on
pourra tjr l'améliorer plus tard.

Ce que je veux dire, c'est que tu peux apporter une nouvelle
fonctionnalité Í  ton programme et que cette fonctionnalité va nécessiter
va nécessiter 10Go d'espace disque libre et que du coup, ça peut devenir
important de se mettre Í  le logguer.
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)


(y a-t-il des règles pour déterminer la catégorie de chaque message ?)

Ce que je te dis, c'est que c'est toi qui voit ce qui est important pour
ton programme. Est-ce que c'est une erreur grave qui l'empêche de
tourner ? Est-ce que c'est juste une précision du fichier de conf que tu
as choisis ? Est-ce que c'est parce que ton programme a un comportement
bizarre alors il faut tout logguer pour comprendre ce qu'il fait
vraiment ligne par ligne ?
Mon idée, c'est que tu te programmes une fonction genre
« sendlog(niveau,message) »

Et c'est ta fonction sendlog qui va choisir quoi faire de tes logs :
poubelle si c'est pas le bon niveau de logs et envoi dans le cas
contraire.

ok, je comprend mieux :-)
je croyais que tu disais de mettre un tag dans le fichier de log, pour
pouvoir ensuite le relire en filtrant (par ex avec grep), et
éventuellement le répartir en plusieurs fichiers par la suite.

Tu as les deux en fait. À partir du moment o͹ tu reçois le niveau de log
pour savoir s'il faut l'envoyer ou pas, tu mets le tag qui va bien dans
tes logs. Quand tu es en mode debug, ça permet de chercher les erreurs
graves au milieu des centaines de lignes d'information.
De même qu'il faut mettre l'heure Í  laquelle tu loggues le message. Le
tag et l'heure ne sont pas plus compliqués Í  ajouter mais tu en verras
l'utilité le jour o͹ tu auras des milliers de lignes de log Í  analyser.
en fait tu dis juste de sélectionner ce qu'on affiche, et que c'est
suffisant au niveau de l'ergonomie pour ne générer qu'un seul fichier de
log.
(dis moi si je me trompe Í  nouveau)

Ce que je dis, c'est qu'en faisant les deux, tu peux tout mettre dans le
même fichier de logs. Parce que des fois, tu as un log normal informatif
qui arrive systématiquement juste avant une erreur grave et de faire la
corrélation entre les deux va être dur si tu as des fichiers différents.
En temps normal, tu regardes juste si tu as des erreurs pour savoir si
tout est normal. En débuggage, tu cherches tes erreurs et tu lis le
contexte autour.
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) ?

Si c'est une application qui tourne dans un terminal, faut pas que les
logs la rendent inutilisable.

mais si j'ai bien compris, les tags ne sont pas censés se retrouver sur
l'affichage. donc tout va bien :-)

En quoi ça te gêne d'afficher les tags ? C'est pas plus compliqué, c'est
juste un mot défini Í  rajouter. Et lorsque les sorties sont mélangées,
c'est la seule façon de voir rapidement si c'est de l'affichage normal
ou une alerte Í  traiter.
Par exemple, la commande find, si tu
cherches toto.txt avec « find / -name toto.txt » en tant que simple
utilisateur, tu vas avoir l'écran rempli d'erreurs des répertoires que
tu n'as pas le droit de lire. et s'il y a une réponse positive, tu ne
vas pas la voir. Alors tu vas plutÍ´t faire ta recherche avec un
« find / -name toto.txt 2> /dev/null ».

(je n'avais pas encore eu le temps de demander comment faire ça,
merci :-)) )

Pour le /dev/null c'est parce que tu ne veux mettre les messages
d'erreurs directement Í  la poubelle. Mais si tu veux les envoyer par
mail, tu mets un nom de fichier Í  la place. Sous Linux.
Si tu veux, on peut s'arrêter lÍ , tu poses des questions, moi je
réponds. Ce que je te donne comme réponses, ce sont surtout les
questions Í  te poser pour comprendre l'impact de ce que tu vas mettre en
place.
--
Si vous avez du temps Í  perdre :
https://scarpet42.gitlab.io
Avatar
Thomas
In article ,
Stéphane CARPENTIER wrote:
Le 27-09-2021, Thomas a écrit :
In article ,
Stéphane CARPENTIER wrote:
Il n'y a rien de compliqué. Si tu balances tous tes logs sur ta sortie
d'erreur, tu dis Í  l'utilisateur de tapper la commande
« $> monsuperprogramme 2> fichier.log »
et de t'envoyer le fichier « fichier.log » quand il a reproduit le bug.

et pour Windows,
je vais sur un forum Windows pour demander comment faire, et ensuite je
transmet Í  l'utilisateur la réponse qu'on me donne sans l'avoir
pratiquée.
ou alors je lui répond "vas sur un forum Windows pour demander comment
on fait ça, moi je sais pas".

Oui, bon, alors effectivement, Windows, je ne connais pas, je ne sais
pas comment ça marche et c'est pas mon problème. Mes réponses sont
orientées unix. Dans les grandes lignes ça doit pouvoir s'adapter sur
Windows mais je ne sais pas comment.

moi non plus je ne sais pas comment,
et j'ai expliqué Í  Marc pourquoi j'en faisais mon problème quand même.
d'o͹ la solution de fabriquer les fichiers de log directement par
l'exécutable, que je trouve la moins mauvaise,
et la contrainte de te déranger le moins possible vient juste après ça,
en termes de priorités.
En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être
rapporté.

je crois qu'on s'est entendu avec Marc sur le fait qu'il n'y avait pas
de nécessité Í  cet endroit.
et si qqn d'autre me fais changer d'avis plus tard ... tant pis, on
pourra tjr l'améliorer plus tard.

Ce que je veux dire, c'est que tu peux apporter une nouvelle
fonctionnalité Í  ton programme et que cette fonctionnalité va nécessiter
va nécessiter 10Go d'espace disque libre et que du coup, ça peut devenir
important de se mettre Í  le logguer.

en fait quand je voyais le nb de cas de figures possibles, qui
s'approche de 27,
s'il fallait rapporter sur toutes les interfaces qui ne posent pas de pb
tous les pbs des interfaces qui en posent,
je me disais que c'était plus simple de tout ignorer.
mais s'il n'y a que qqes cas particuliers dans lesquels c'est préférable
de rapporter les pbs d'une interface sur une autre, ça devient bcp plus
simple. :-)
>> 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)

(y a-t-il des règles pour déterminer la catégorie de chaque message ?)

Ce que je te dis, c'est que c'est toi qui voit ce qui est important pour
ton programme. Est-ce que c'est une erreur grave qui l'empêche de
tourner ? Est-ce que c'est juste une précision du fichier de conf que tu
as choisis ? Est-ce que c'est parce que ton programme a un comportement
bizarre alors il faut tout logguer pour comprendre ce qu'il fait
vraiment ligne par ligne ?

ok.
je devine que je trouverai l'usage au fur et Í  mesure que j'en aurai
besoin.
il faut que j'ai Í  l'idée qu'on peut ajouter autant de niveaux qu'on
veut.
en attendant, ça ne dérange personne que je reste Í  2. :-)
Mon idée, c'est que tu te programmes une fonction genre
« sendlog(niveau,message) »

Et c'est ta fonction sendlog qui va choisir quoi faire de tes logs :
poubelle si c'est pas le bon niveau de logs et envoi dans le cas
contraire.

ok, je comprend mieux :-)
je croyais que tu disais de mettre un tag dans le fichier de log, pour
pouvoir ensuite le relire en filtrant (par ex avec grep), et
éventuellement le répartir en plusieurs fichiers par la suite.

Tu as les deux en fait. À partir du moment o͹ tu reçois le niveau de log
pour savoir s'il faut l'envoyer ou pas, tu mets le tag qui va bien dans
tes logs. Quand tu es en mode debug, ça permet de chercher les erreurs
graves au milieu des centaines de lignes d'information.
De même qu'il faut mettre l'heure Í  laquelle tu loggues le message. Le
tag et l'heure ne sont pas plus compliqués Í  ajouter mais tu en verras
l'utilité le jour o͹ tu auras des milliers de lignes de log Í  analyser.

C'est pas très compliqué Í  ajouter, surtout si on se contente de
l'ajouter et peu importe ce que ça devient.
C'est un tout petit peu plus compliqué que ça, si on veut se garantir de
faire les choses "bien comme il faut", ce qui implique qques questions
supplémentaires, même si Í  la fin on fait la même chose que sans se
poser de question.
par exemple :
- si le msg Í  rapporter s'étale sur plusieurs lignes ?
- est-ce qu'on le découpe en tranches et on remet les metadonnées sur
chaque ligne ?
- est-ce qu'on remplace le marqueur de fin de ligne par un autre
séparateur ?
- si on veut que ça soit exploitable en tableur il faut choisir un
séparateur :
lequel, et comment ça se passe si le msg Í  rapporter le contient ?
en fait tu dis juste de sélectionner ce qu'on affiche, et que c'est
suffisant au niveau de l'ergonomie pour ne générer qu'un seul fichier de
log.
(dis moi si je me trompe Í  nouveau)

Ce que je dis, c'est qu'en faisant les deux, tu peux tout mettre dans le
même fichier de logs. Parce que des fois, tu as un log normal informatif
qui arrive systématiquement juste avant une erreur grave et de faire la
corrélation entre les deux va être dur si tu as des fichiers différents.
En temps normal, tu regardes juste si tu as des erreurs pour savoir si
tout est normal. En débuggage, tu cherches tes erreurs et tu lis le
contexte autour.

je comprend bien l'intérêt :-)
en suivant les recommandations de Marc, on peut choisir de tout mettre
dans le même fichier de logs, soit en dirigeant les 2 sorties standards
au même endroit, soit en donnant le même nom aux 2 fichiers.
> 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) ?
Si c'est une application qui tourne dans un terminal, faut pas que les
logs la rendent inutilisable.

mais si j'ai bien compris, les tags ne sont pas censés se retrouver sur
l'affichage. donc tout va bien :-)

En quoi ça te gêne d'afficher les tags ? C'est pas plus compliqué, c'est
juste un mot défini Í  rajouter. Et lorsque les sorties sont mélangées,
c'est la seule façon de voir rapidement si c'est de l'affichage normal
ou une alerte Í  traiter.

C'est pas compliqué, le pb c'est tjr de savoir ce qui est bien.
je trouverais ça bizarre d'avoir le msg "ignoring unknown switch" ainsi
que le "usage: ..." qui suit, bardés de tags + horodatage !
est-ce que ça se pratique ?
Par exemple, la commande find, si tu
cherches toto.txt avec « find / -name toto.txt » en tant que simple
utilisateur, tu vas avoir l'écran rempli d'erreurs des répertoires que
tu n'as pas le droit de lire. et s'il y a une réponse positive, tu ne
vas pas la voir. Alors tu vas plutÍ´t faire ta recherche avec un
« find / -name toto.txt 2> /dev/null ».

Pour le /dev/null c'est parce que tu ne veux mettre les messages
d'erreurs directement Í  la poubelle.

je n'ai pas compris. "ne" est en trop ?
Ce que je te donne comme réponses, ce sont surtout les
questions Í  te poser pour comprendre l'impact de ce que tu vas mettre en
place.

merci :-)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
Thomas
In article
,
Thomas wrote:
In article ,
Stéphane CARPENTIER wrote:
Le 27-09-2021, Thomas a écrit :
> In article ,
> Stéphane CARPENTIER wrote:

>> En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être
>> rapporté.
>
> je crois qu'on s'est entendu avec Marc sur le fait qu'il n'y avait pas
> de nécessité Í  cet endroit.
> et si qqn d'autre me fais changer d'avis plus tard ... tant pis, on
> pourra tjr l'améliorer plus tard.
Ce que je veux dire, c'est que tu peux apporter une nouvelle
fonctionnalité Í  ton programme et que cette fonctionnalité va nécessiter
va nécessiter 10Go d'espace disque libre et que du coup, ça peut devenir
important de se mettre Í  le logguer.

en fait quand je voyais le nb de cas de figures possibles, qui
s'approche de 27,
s'il fallait rapporter sur toutes les interfaces qui ne posent pas de pb
tous les pbs des interfaces qui en posent,
je me disais que c'était plus simple de tout ignorer.
mais s'il n'y a que qqes cas particuliers dans lesquels c'est préférable
de rapporter les pbs d'une interface sur une autre, ça devient bcp plus
simple. :-)

d'après moi :
- on peut tout ignorer en cas de pb avec l'interface graphique, parce
que ça ne peut pas arriver uniquement Í  cet endroit, ça arrivera
forcément ailleurs.
- on peut tout ignorer en cas de pb avec les fichiers de log, parce que
c'est facultatif.
si je t'ai bien compris :
en cas de pb avec stdout / stderr,
- si l'interface graphique est disponible, on affiche ça dedans,
parce que dans ce cas c'est probable que stdout et stderr ne soient pas
lus (redirigés ou jetés).
- si non, on l'envoie sur stdout,
parce que dans ce cas c'est probable que stderr ne soit pas lu
(redirigé),
mais c'est probable que stdout le soit (directement dans un terminal).
- dans tous les cas, si on obtient des erreurs supplémentaires, on les
ignore.
est-ce que ça te parait correct ?
>> >> Par exemple, tu mets
>> >> du
>> >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un
>> >> niveau
>> >> d'activation faible en temps normal


est-ce que je numérote dans cet ordre de 0 Í  3 ?
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
Thomas
In article
,
Thomas wrote:
> >> >> Par exemple, tu mets
> >> >> du
> >> >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un
> >> >> niveau
> >> >> d'activation faible en temps normal

est-ce que je numérote dans cet ordre de 0 Í  3 ?

peut-être plutÍ´t dans l'autre sens :
en commençant par le plus important et en allant vers le plus facultatif.
dis moi si t'y vois un inconvénient.
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
Stéphane CARPENTIER
Le 19-12-2021, Thomas a écrit :
- on peut tout ignorer en cas de pb avec l'interface graphique, parce
que ça ne peut pas arriver uniquement Í  cet endroit, ça arrivera
forcément ailleurs.

Ben justement voilÍ  justement une bonne raison de ne pas chercher Í 
logguer Í  plein d'endroits différents en fonction du contexte. Imagine,
ton application elle tourne nickel en terminal. Ton utilisateur veut
l'utiliser avec l'interface graphique. Sauf que comme tu n'as pas
exactement les mêmes librairies avec Wayland et Xorg, ça peut marcher
sur l'un et pas sur l'autre.
Si tu veux analyser tous les cas possibles, ça va être très délicat. Si
tu te contentes de balancer les logs et de laisser l'utilisateur en
faire ce qu'il veut ça te simplifie la vie.
en cas de pb avec stdout / stderr,

Ce qui est bien avec stdout/stderr, c'est que s'il y a un problème,
l'utilisateur le redirige vers un autre endroit o͹ il n'y a pas de
problème.
- si l'interface graphique est disponible, on affiche ça dedans,
parce que dans ce cas c'est probable que stdout et stderr ne soient pas
lus (redirigés ou jetés).

L'affichage dans l'interface graphique, c'est pour afficher une
information qui demande une intervention de l'utilisateur Í  un moment.
C'est pas forcément une erreur.
Par exemple, si l'utilisateur n'a pas choisi la couleur de son fond
d'écran mais que tu as une couleur par défaut, c'est pas très important.
Lorsqu'il change la couleur de son fond d'écran mais qu'il y a un
problème et que tu gardes la couleur par défaut, il faut l'informer que
son action s'est mal passée.
Si par contre, ton application exécute une action en tÍ¢che de fond
toutes les minutes, si l'action plante une fois sur deux, il faut le
logguer mais ne pas lui afficher la pop-up toutes les deux minutes. Ce
n'est pas forcément grave si stdout et stderr ne sont pas lus. Si
l'utilisateur veut chercher Í  comprendre après coup, il les lira.
- si non, on l'envoie sur stdout,
parce que dans ce cas c'est probable que stderr ne soit pas lu
(redirigé),
mais c'est probable que stdout le soit (directement dans un terminal).

En fait, l'intérêt de sdout et de stderr, c'est que tu t'en cognes de
savoir si c'est lu ou pas, redirigé ou pas. Tu donnes une information et
l'utilisateur en fait ce qu'il veut.
La différence entre les deux, c'est que le stdout, c'est pour
l'information normale et le stderr c'est pour l'erreur. Par exemple, si
ton application exécute une tÍ¢che de fond toutes les minutes, dans ton
stdout, tu vas logguer le début et la fin de l'action. Et s'il y a un
plantage, tu loggues l'erreur dans le stderr.
Comme ça, si l'utilisateur redirige tout dans le même fichier, il aura
le contexte : le plantage aura eu lieu pendant la t͢che de fond. Mais
s'il veut se concentrer sur les erreurs, il ne regarde que stderr. Tu le
laisses choisir le niveau d'information qu'il veut afficher.
Et si dans tes logs, tu précises ce que c'est (avec un timestamp devant) :
INFO: début de la tÍ¢che de fond
INFO: 42 informations Í  mettre Í  jour
WARNING: 1 mise Í  jour est vide, utilisation de la valeur TOTO
ERROR: enregistrement impossible, droits insuffisants
INFO: fin de la t͢che de fond
LÍ , comme en général, tu vas avoir des centaines de lignes d'info pour
quelques lignes d'erreur, il va pouvoir faire des recherches faciles.
>> >> Par exemple, tu mets
>> >> du
>> >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un
>> >> niveau
>> >> d'activation faible en temps normal


est-ce que je numérote dans cet ordre de 0 Í  3 ?

En général, le plus simple est d'utiliser un framework qui fait déjÍ 
tout ça et de suivre la doc.
--
Si vous avez du temps Í  perdre :
https://scarpet42.gitlab.io
Avatar
Thomas
In article ,
Stéphane CARPENTIER wrote:
Le 19-12-2021, Thomas a écrit :
en cas de pb avec stdout / stderr,

Ce qui est bien avec stdout/stderr, c'est que s'il y a un problème,
l'utilisateur le redirige vers un autre endroit o͹ il n'y a pas de
problème.

pour ça il faut qu'il s'aperçoive du pb, puis qu'il redémarre
l'application avec les bons paramètres.
c'est pour ça (je crois) que tu m'avais dit que c'était pas bien
d'ignorer les erreurs.
Si par contre, ton application exécute une action en tÍ¢che de fond
toutes les minutes, si l'action plante une fois sur deux, il faut le
logguer mais ne pas lui afficher la pop-up toutes les deux minutes. Ce
n'est pas forcément grave si stdout et stderr ne sont pas lus. Si
l'utilisateur veut chercher Í  comprendre après coup, il les lira.

si le disque est plein,
- il faut le logguer ou ?
- tu trouves que ça ne convient pas de signaler ce pb dans l'interface
graphique ?
ça ne convient pas de considérer que ce pb doit être résolu
immédiatement pour que le logiciel puisse continuer Í  fonctionner
correctement ?
- si non, on l'envoie sur stdout,
parce que dans ce cas c'est probable que stderr ne soit pas lu
(redirigé),
mais c'est probable que stdout le soit (directement dans un terminal).

En fait, l'intérêt de sdout et de stderr, c'est que tu t'en cognes de
savoir si c'est lu ou pas, redirigé ou pas. Tu donnes une information et
l'utilisateur en fait ce qu'il veut.

et si le disque est plein ?
La différence entre les deux, c'est que le stdout, c'est pour
l'information normale et le stderr c'est pour l'erreur. Par exemple, si
ton application exécute une tÍ¢che de fond toutes les minutes, dans ton
stdout, tu vas logguer le début et la fin de l'action. Et s'il y a un
plantage, tu loggues l'erreur dans le stderr.
Comme ça, si l'utilisateur redirige tout dans le même fichier, il aura
le contexte : le plantage aura eu lieu pendant la t͢che de fond. Mais
s'il veut se concentrer sur les erreurs, il ne regarde que stderr. Tu le
laisses choisir le niveau d'information qu'il veut afficher.

c'est comme ça que je suis parti pour l'instant.
Et si dans tes logs, tu précises ce que c'est (avec un timestamp devant) :
INFO: début de la tÍ¢che de fond
INFO: 42 informations Í  mettre Í  jour
WARNING: 1 mise Í  jour est vide, utilisation de la valeur TOTO
ERROR: enregistrement impossible, droits insuffisants
INFO: fin de la t͢che de fond
LÍ , comme en général, tu vas avoir des centaines de lignes d'info pour
quelques lignes d'erreur, il va pouvoir faire des recherches faciles.

a priori c'est une idée que je trouve pas mauvaise.
mais il y a des questions non répondues, dans mon msg du 22 Oct 2021,
qui font que je n'y vais pas pour l'instant.
> >> >> Par exemple, tu mets
> >> >> du
> >> >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un
> >> >> niveau
> >> >> d'activation faible en temps normal

est-ce que je numérote dans cet ordre de 0 Í  3 ?

En général, le plus simple est d'utiliser un framework qui fait déjÍ 
tout ça et de suivre la doc.

en ada, on a Í  ma connaissance toutes les bibliothèques nécessaires pour
avoir toutes les possibilités de développement Í  disposition,
mais il n'y a pas autant de bibliothèques qu'en c quand même.
je suppose que c'est pour ça que mon prédécesseur avant démarré
l'écriture d'une telle bibliothèque.
je l'ai immédiatement "améliorée" en ajoutant la génération de
fichiers log, parce que c'était un besoin et que je ne savais pas que
c'était mal vu.
et lÍ , je continue de l'améliorer, par ex en rendant ces fichiers log
facultatifs, et en permettant de choisir leur nom.
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
garkbeda43
Le lundi 05 Juillet 2021 à 21:41 par Thomas :
bonjour :-)
j'ai des logs Í  gérer, et j'aimerais mieux ne pas les
effacer quand j'ai
besoin de place pour un nouveau fichier.
j'ai regardé ce qui se passe dans /var/log/ :
est ce que c'est qqch de plus ou moins normalisé, ou est ce qu'on fait
vraiment ce qu'on veut ?
1
j'aime bcp l'idée d'avoir un n° que je peux incrementer
jusqu'Í 
l'infini, pas de limite supérieure :-)
2
le gros pb, c'est que ça ajoute le n° après l'extension
plutÍ´t qu'avant.
du coup, mon éditeur de texte croit avoir affaire Í  des
pages de man
plutÍ´t qu'Í  des logs !
quel genre de pb ça peut poser si je décide de faire
différemment ?
et pendant que j'y suis, pourquoi ne pas corriger ça au niveau du
système ?
3
apparemment, quand on a besoin de place, on décale tous les fichiers
d'un cran.
si Í  la place je met juste le dernier n° (le 1er dispo) au
fichier qui
n'en a pas encore, sans toucher aux autres, qu'est ce que vous en dites ?
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Je crois que pour le moment je ne comprends pas l'objectif de
ton application.
4 5 6 7 8