NOM
logger - Ajouter des messages au journal systèmeSYNOPSIS
logger [options] messageDESCRIPTION
logger ajoute des entrées dans le journal système.OPTIONS
-d, --udpN’utiliser que les datagrammes (UDP).
Par défaut la connexion est tentée sur le port de syslog
défini dans /etc/services, qui est généralement
514.
Voir aussi --server ou --socket pour définir où se
connecter.
Ignorer les lignes vides lors du traitement
des fichiers. Une ligne vide est définie comme une ligne sans
caractère. Ainsi, une ligne ne contenant que des espaces n’est
pas considérée vide. Remarquez que si l’option
--prio-prefix est indiquée, la priorité ne fait pas
partie de la ligne. Ainsi, une ligne vide dans ce mode est une ligne qui
n’a pas de caractère après la priorité (par
exemple, <13>).
Enregistrer le contenu du fichier
indiqué. Cette option ne peut pas être associée à
un message de ligne de commande.
Enregistrer le PID du processus logger
sur chaque ligne.
Enregistrer le PID du processus logger
sur chaque ligne. Quand l’argument facultatif id est
indiqué, il est utilisé à la place du PID de la commande
logger. L’utilisation de --id=$$ (PPID) est
recommandée dans les scripts qui envoient plusieurs messages.
Remarquez que l'infrastructure de journalisation du système (par exemple
systemd écoutant sur /dev/log) peut suivre les droits de
la socket locale pour écraser le PID spécifié dans le
message. peut définir ces droits de socket à
l’ id donné, mais seulement si vous avez les droits de
superutilisateur et que le processus avec le PID indiqué existe, sinon
les droits de la socket ne sont pas modifiés et le problème est
ignoré en silence.
Écrire une entrée de journal
systemd. L’entrée est lue du fichier donné
s’il est indiqué, ou sinon de l’entrée standard.
Chaque ligne doit commencer par un champ accepté par journald,
consultez systemd.journal-fields(7) pour plus de précisons.
L’utilisation du champ MESSAGE_ID est généralement une
bonne idée car cela facilite la recherche d’entrées.
Exemples :
logger --journald <<end MESSAGE_ID=67feb6ffbaf24c5cbec13c008dd72309 MESSAGE=Les chiens aboient mais la caravane passe. CHIENS=aboient CARAVANE=passe end
logger --journald=entrée.txt
Définir le RFC 5424
<https://tools.ietf.org/html/rfc5424> champ MSGID. Remarquez que le
caractère espace n’est pas permis à
l’intérieur de msgid. Cette option n’est
utilisée que si --rfc5424 est indiquée aussi. Sinon, elle
est ignorée silencieusement.
Écrire sur le serveur syslog
distant indiqué au lieu de la socket du journal système.
À moins que --udp ou --tcp ne soient indiquées,
logger essaiera d’abord d’utiliser UDP, mais si cela
échoue, une connexion TCP sera tentée.
Forcer chaque chose à être
faite, à part l’écriture du message dans le journal
système et la fermeture de la connexion au journal. Cette option est
utilisable avec --stderr pour faire des tests.
Utiliser RFC 6587
<https://tools.ietf.org/html/rfc6587> la méthode de comptage
d'octets par tramage pour l'envoi de messages. Quand cette option n'est pas
utilisée, le comportement par défaut est l’absence de
tramage (framing) sur UDP, et sur TCP s'applique le tramage non transparent de
la RFC 6587 (connu aussi sous le nom de remplissage d'octets
(stuffing)).
Utiliser le port indiqué. Quand
cette option n’est pas indiquée, le port par défaut de
syslog est utilisé pour les connexions UDP et celui de
syslog-conn pour les connexions TCP.
Enregistrer le message dans le journal avec la
priorité indiquée. La priorité peut être
donnée numériquement ou bien avec un couple
service. niveau. Par exemple,
-p local3.info enregistre le message comme informationnel dans
le service local3. La valeur par défaut est
user.notice.
Chercher un préfixe syslog sur toutes
les lignes lues sur l’entrée standard. Ce préfixe est un
nombre décimal entre chevrons qui encode à la fois le service et
le niveau. Le nombre est construit en multipliant le service par 8 et
en ajoutant le niveau. Par exemple, local0.info, signifiant de
service 16 et de niveau 6, devient <134>.
Si le préfixe ne contient pas de service, le service par défaut
est celui indiqué par l’option -p. De même, si
aucun préfixe n’est fourni, la ligne est journalisée en
utilisant la priorité donnée avec -p.
Cette option n’affecte pas un message de ligne de commande.
Utiliser RFC 3164
<https://tools.ietf.org/html/rfc3164> le protocole syslog BSD pour
soumettre des messages à un serveur distant.
Utiliser RFC 5424
<https://tools.ietf.org/html/rfc5424> le protocole syslog pour envoyer
des messages à un serveur distant. L'argument facultatif sans
peut être une liste, séparée par des virgules, des
arguments suivants : notq, notime, nohost.
La valeur notq supprime la donnée structurée time-quality
du message envoyé. Les informations time-quality indiquent si l'horloge
locale était synchronisée et le nombre maximum de microsecondes
où l'horodatage pourrait ne pas être actif. La précision
du temps est supprimée automatiquement quand
--sd-id timeQuality est spécifié.
La valeur notime (qui implique notq) supprime tout l'horodatage de
l'expéditeur au format ISO-8601, notamment les microsecondes et les
fuseaux horaires.
La valeur nohost supprime les informations gethostname(2) de
l'entête du message.
Le protocole RFC 5424 est utilisé par défaut par
logger depuis la version 2.26.
Afficher le message sur la sortie d'erreur
standard en plus de l'enregistrer dans le journal système.
Spécifier l'identifiant d'un
élément de données structurées pour
l'entête d'un message conforme à la RFC 5424. L'option
doit être utilisée avant --sd-param pour ajouter de
nouveaux éléments. Le nombre d'éléments de
données structurées n'est pas limité. L'identifiant (
nom plus éventuellement @chiffres) est sensible
à la casse et n'identifie que le type et l'objectif d'un
élément. Le même identifiant ne doit pas
apparaître plusieurs fois dans un message. La partie
@chiffres est nécessaire pour les identifiants non
standardisés et définis par l'utilisateur.
logger ne génère actuellement que l'élément
standardisé timeQuality. La RFC 5424 décrit aussi
les éléments origin (avec les paramètres
ip, enterpriseId, software et swVersion) et
meta (avec les paramètres sequenceId, sysUpTime et
language). Ces identifiants d'éléments peuvent
être spécifiés sans le suffixe
@chiffres.
Spécifier le paramètre d'un
élément de données structurées, une paire nom et
valeur. L'option doit être utilisée après --sd-id
et peut être spécifiée plus d'une fois pour le
même élément. Remarquez que les guillemets autour de
valeur sont nécessaires et doivent être
protégés sur la ligne de commande.
produit :
<13>1 2015-10-01T14:07:59.168662+02:00 ws kzak - - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="218616"][zoo@123 tiger="hungry" zebra="running"][manager@123 onMeeting="yes"] this is message
logger --rfc5424 --sd-id zoo@123 \ --sd-param tiger="hungry" \ --sd-param zebra="running" \ --sd-id manager@123 \ --sd-param onMeeting="yes" \ "this is message"
<13>1 2015-10-01T14:07:59.168662+02:00 ws kzak - - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="218616"][zoo@123 tiger="hungry" zebra="running"][manager@123 onMeeting="yes"] this is message
Définir la taille maximale
permise par message. La valeur par défaut est de 1 kio en
caractères, qui est la limite traditionnelle telle
qu’indiquée dans la RFC 3164. Avec la RFC 5424,
cette limite est devenue flexible. En général, les destinataires
RFC 5424 peuvent au moins traiter des messages de 4 kio.
La plupart des destinataires acceptent des messages plus grands que 1 kio
sur tous les types de protocole de journal système. Ainsi,
l’option --size affecte logger dans tous les cas (pas
seulement quand --rfc5424 est utilisée).
Remarque : la taille maximale de message limite la taille totale du
message, y compris l’en-tête de journal système. Les
tailles d’en-tête varient en fonction des options
sélectionnées et de la taille du nom d’hôte. En
règle générale, les en-têtes ne dépassent
pas 50 ou 80 caractères. Lors de la sélection de la
taille maximale du message, s’assurer que le destinataire puisse
recevoir des messages de cette taille est important, sinon les messages
pourraient être tronqués. De nouveau, en règle
générale, des messages de deux à quatre kilooctets
devraient normalement passer, alors que tout ce qui dépasse devrait
être vérifié.
Afficher les erreurs sur les connexions de
socket UNIX. Le mode peut prendre la valeur off, on ou
auto. En mode auto, logger détectera si le
processus d’initialisation est systemd(1), et si cette
hypothèse est exacte, /dev/log peut être utilisé
tôt au démarrage. L’absence de /dev/log des autres
systèmes d’initialisation ne provoquera pas d’erreur, ce
qui est identique à l’envoi de messages en utilisant
l’appel système openlog(3). avant la
version 2.26 utilisait openlog(3) et était donc incapable
de détecter la perte de messages envoyés aux sockets UNIX.
Le mode par défaut est auto. Quand les erreurs ne sont pas
activées, les messages perdus ne sont pas communiqués, ce qui
donne un état de sortie indiquant la réussite de l’appel
de .
N’utiliser que les flux (TCP). Par
défaut la connexion est tentée sur le port de syslog-conn
défini dans /etc/services, qui est généralement
601.
Voir aussi --server ou --socket pour définir où se
connecter.
Placer une étiquette sur chaque
ligne du journal. L’étiquette par défaut est le nom de
l'utilisateur connecté au terminal (ou le nom d'un utilisateur à
partir de son identifiant réel).
Écrire dans la socket
indiquée au lieu d'utiliser la socket du journal système.
Terminer la liste des arguments. Cela permet
au message de commencer avec un tiret
(« - »).
Afficher l’aide-mémoire puis
quitter.
Afficher la version puis quitter.
CODE DE RETOUR
Le code de retour est 0 quand logger réussit et strictement supérieur à 0 en cas d'erreur.SERVICES ET NIVEAUX
Les noms de services possibles sont :CONFORMITÉ
La commande logger est prévue pour être compatible avec IEEE Std 1003.2 (« POSIX.2 »).EXEMPLES
logger System rebooted logger -p local0.notice -t HOSTIDM -f /dev/idmc logger -n loghost.example.com System rebootedAUTEURS
La commande logger a été écrite à l'origine par l'université de Californie entre 1983-1993, puis réécrite par Karel <[email protected]>Zak Rainer <[email protected]>Gerhards et Sami <[email protected]>KerolaVOIR AUSSI
journalctl(1), syslog(3), systemd.journal-fields(7)SIGNALER DES BOGUES
Pour envoyer un rapport de bogue, utilisez le système de gestion des problèmes à l'adresse <https://github.com/util-linux/util-linux/issues>.DISPONIBILITÉ
La commande logger fait partie du paquet util-linux téléchargeable sur Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.TRADUCTION
La traduction française de cette page de manuel a été créée par Christophe Blaess <[email protected]>, Michel Quercia <quercia AT cal DOT enst DOT fr>, Thierry Vignaud <[email protected]>, Frédéric Delanoy <[email protected]>, Thierry Vignaud <[email protected]>, Christophe Sauthier <[email protected]>, Sébastien Blanchet, Jérôme Perzyna <[email protected]>, Aymeric Nys <aymeric AT nnx POINT com>, Alain Portal <[email protected]>, Thomas Huriaux <[email protected]>, Yves Rütschlé <[email protected]>, Jean-Luc Coulon (f5ibh) <[email protected]>, Julien Cristau <[email protected]>, Philippe Piette <[email protected]>, Jean-Baka Domelevo-Entfellner <[email protected]>, Nicolas Haller <[email protected]>, Sylvain Archenault <[email protected]>, Valéry Perrin <[email protected]>, Jade Alglave <[email protected]>, Nicolas François <[email protected]>, Alexandre Kuoch <[email protected]>, Lyes Zemmouche <[email protected]>, Florentin Duneau <[email protected]>, Alexandre Normand <[email protected]>, David Prévot <[email protected]> et Jean-Philippe MENGUAL <[email protected]> Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à [email protected]11 mai 2022 | util-linux 2.38.1 |