guildamo a écrit :Le hic c'est que je me rends compte que ca a coupé quand je rentre le soir (une lumière qui ne s'allume pas, le portail qui reste fermé..) et la Z-Stcik peut être déconnectée depuis plusieurs heures
Il faut donc lancer un dmesg en SSH quand la connexion est perdue ? Je doit y chercher quoi ? Comment je configure grep pour "cibler" la coupure ? (Que de questions !)
Je suis totalement incompétent en linux, merci de votre aide par avance
grep est un filtre prenant un motif en argument et tout les unices ont ceci de bien qu'ils intègrent... le manuel. Dans un terminal, "man grep" donnera l'usage. Même si on ne connaît pas précisément la commande à utiliser, c'est prévu pourvu qu'on ait un mot clef: "man -k KeyWord". Ici, "man -k motif" donne les commandes de filtrage sur motif/chaine de caractère par exemple, même si on ne les connait pas. Suffit d'avoir un mot clef pertinent pour trouver la/les commandes pouvant résoudre son problème.
Si c'est plusieurs heures après, il faudra sans doute regarder les fichiers de log, généralement dans le répertoire /var/log. Les noms peuvent cependant varier un peu... Au pire, ne pas être fin et le lancer sur tout le répertoire:
En root ou éventuellement précédé d'un sudo (si le compte utilisé est "sudoer"): Va donner toutes les lignes de log ou un disconnect apparait, sans tenir compte des minuscules/majuscules (rôle de l'option -i).
Comme cela risque de ne pas donner que des lignes relatives à l'usb, on peut aussi filtrer la sortie standard par un second niveau de grep via un tube (caractère "|"):
On entrevoit alors à peine toute la puissance de la ligne de commande vs les clicodromes pour trouver ce qu'on cherche dans des dizaines de fichiers comportant potentiellement des dizaines de milliers de lignes en un claquement de doigts.
Ce qui chez moi donne:
/var/log/kern.log.1:Mar 13 17:20:18 kernel: [19490.930503] usb 4-1.1: USB disconnect, device number 6
/var/log/messages.1:Mar 13 17:20:18 kernel: [19490.930503] usb 4-1.1: USB disconnect, device number 6
C'est le même évènement sorti des logs kernel et message, au 1er niveau d'archivage (d'ou le .1 ajouté au nom de fichier, non encore compressé) (qui est en fait le contenu archivé du dmesg=debug messages): La dernière fois ou j'ai débranché ma z-stick pour associer un nouveau module en fait, donc ici ce n'est pas anormal.
Si c'est encore plus ancien, attention au logrotate qui va compresser régulièrement les fichiers de log (au delà du courant et du 1er niveau d'archivage) avant de poursuivre. Dans ce cas, utiliser zgrep qui va décompresser à la volée à la place de grep (sur le 1er niveau relatif au fichier).
Si c'est tout récent, le dmesg suffira. Filtrer sa sortie standard tout pareil:
.
