Bonjour,
essayant de m’instruire sur systemd, j’ai testé systemctl status qui me renvoie «dégradé».
Comment mener l’enquête si nécessaire pour réparer leopard-1 (Trixie)?
Effectivement je me souviens avoir démarré plusieurs fois dans un mode rescue (ou quelque-chose de cet ordre)
● leopard-1
State: degraded
Units: 647 loaded (incl. loaded aliases)
Jobs: 0 queued
Failed: 4 units
Since: Tue 2026-08-25 20:52:29 CEST; 3 weeks 5 days ago
systemd: 257.13-1~deb13u1essai ça :
systemctl --failed
Ça signifie juste que l’un des services est en état Active: failed
Et avec la commande de @Clochette systemctl --failed status tu sauras le ou lesquels
en l’occurence tu en as 4:
● leopard-1
State: degraded
Units: 647 loaded (incl. loaded aliases)
Jobs: 0 queued
Failed: 4 units
Bonjour,
lire la page de manuel est très instructif
degraded Le système est opérationnel mais une ou plusieurs unités sont en échec.
status [ MOTIF …| PID …]]
Afficher les informations d’état de fonctionnement du système entier
Si aucun argument de position n’est indiqué et qu’aucun filtre d’unité n’est donné avec –type= , –state= ou –failed , l’état de tout le système est affiché. Si cette option est combinée avec –all , l’affichage est complété par l’état de toutes les unités.
systemctl(1) — manpages-fr — Debian trixie — Debian Manpages
Merci Clochette et Zargos,
UNIT LOAD ACTIVE SUB DESCRIPTION
● etckeeper.service loaded failed failed Autocommit of changes in /etc directory
● log2ram-daily.service loaded failed failed Daily Log2Ram writing activities
● log2ram.service loaded failed failed Log2Ram
● me.proton.vpn.split_tunneling.service loaded failed failed Proton VPN Daemon
Legend: LOAD → Reflects whether the unit definition was properly loaded.
ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
SUB → The low-level unit activation state, values depend on unit type.
J’essaie de comprendre les 4 commandes systemctl status pour chaque service concerné.
Je vous donnerai la suite dés que je serais disponible.
merci à tous les trois
Tu peux te faciliter la vie avec la commande suivante :
journalctl -xeu etckeeper.service
Tu adaptes le nom de l’unit service et si il dispose de journaux à lui tu pourra les consulter plus rapidement.
juste pour info, tu utilises des cartes SD pour /var/log sur un RPI?
Car un inconvénient de log2ram, outre la consommation de RAM, c’est le fait qu’on peut facilement les compromettre.
merci Zargos, mais je ne comprends pas cette question.
Il m’arrive d’introduire des cartes SD d’appareil photo, pour les transférer et (pas depuis des mois voire des années) pour des sauvegardes. Je ne sais ce qu’est un RPI, et n’utilise pas volontairement et consciemment /var/log sauf pour lire parfois ce qu’il contient.
merci clochette, mais j’avoue ne pas bien savoir que faire de ces informations, ésotériques pour moi.
Raspberry-Pi
C’est une smartcard micro-SD par exemple
C’est cela, la même chose mais tu envoie ton /var/log/ dessus. Auquel cas il est effectivement préférable d’utiliser log2ram, mais sinon c’est inutile.
ta machine est un PC/serveur normal? alors log2ram ne te sert à rien.
? si ça signifie copier /var/log dessus? je ne le crois pas.
Par ailleurs c’est un simple PC portable, donc log2ram ne sert à rien, je désinstalle, encore merci.
Bah ce sont des logs avec quand c’est possible quelques recommandations …
Ne reste plus que le message concernant protonvpn.
D’une part, il semble fonctionner (avec le gui), comme le confirme le site WhatIsMyIp.com.
J’ai commencé à lire le fil Problème Proton VPN sur Debian 13 et à chercher sur mes notes persos.
Je vais risquer un redémarrage sur et voir s’il se passe sans problème sur Trixie
est-ce que tu utilises vraiment le split tunneling?
si tu ne sais pas ce que c’est, alors la réponse est non 
alors, c’est non