Quand tu veux une archi qui n'est pas simplement directement client-serveur, ou alors que tu veux pouvoir ouvrir des canaux de communication annexes (genre FTP passif ; oui, c'est considéré comme « has-been », mais il existerait tellement d'avantages à autoriser ce genre de chose pour des modèles d'interactions nouveaux), ou quand tu veux un contrôle plus fin des erreurs, voire même simplement quand ton protocole est un peu plus complexe que juste du question-réponse en une fois.
syslogd nécessite une connexion sur un socket pour récupérer les logs, et non sur l'entrée standard.
Oui.
Si le but est la simplicité, l'idée de logguer dans stdout plutôt que dans un socket avec le protocole syslog n'est-elle pas bonne?
Je dirais que les entrées-sorties standard sont faites pour l'interaction directe avec ton interlocuteur ; syslog a plutôt un but de log à destination d'autres programmes ou personnes. Donc je ne trouve pas ça illogique.
Si je me souviens bien, la philosophie d'UNIX, c'est de toujours balancer du texte sur les entrées et sorties standard, et pour le coup, je trouve que syslogd y déroge
Si la personne qui peut mieux diagnostiquer le problème n'est pas l'interlocuteur du programme, je pense que ça vaut quand même le coup de passer par syslog. En fait, selon mon intuition, un log est vraiment un flux différent de l'applicatif, et doit pouvoir avoir plusieurs destinations, et va donc mieux dans un descripteur particulier. Mais c'est juste une impression, je ne suis pas un spécialiste des logs.
[^] # Re: L’avenir et le passé
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1. Dernière modification le 06 février 2019 à 14:26.
Quand tu veux une archi qui n'est pas simplement directement client-serveur, ou alors que tu veux pouvoir ouvrir des canaux de communication annexes (genre FTP passif ; oui, c'est considéré comme « has-been », mais il existerait tellement d'avantages à autoriser ce genre de chose pour des modèles d'interactions nouveaux), ou quand tu veux un contrôle plus fin des erreurs, voire même simplement quand ton protocole est un peu plus complexe que juste du question-réponse en une fois.
Oui.
Je dirais que les entrées-sorties standard sont faites pour l'interaction directe avec ton interlocuteur ; syslog a plutôt un but de log à destination d'autres programmes ou personnes. Donc je ne trouve pas ça illogique.
Si la personne qui peut mieux diagnostiquer le problème n'est pas l'interlocuteur du programme, je pense que ça vaut quand même le coup de passer par syslog. En fait, selon mon intuition, un log est vraiment un flux différent de l'applicatif, et doit pouvoir avoir plusieurs destinations, et va donc mieux dans un descripteur particulier. Mais c'est juste une impression, je ne suis pas un spécialiste des logs.