Désolé de ma question ouverte mais je suis complètement planté… Je rallume ce midi et je n’arrive plus à ouvrir le terminal (ctrl T ou fenetre). Idem pour synaptic???
J’avais installé clamav ce matin et linux malware detection, cela serait-il lié? J’ai lancé et interrompu un scan le matin qui ne terminait pas…
Que dois-je regarder d’abord pour corriger ce problème?
Merci!
Ben dans un terminal, tu lances un terminal, et tu regardes les messages d’erreur. 
Plus sérieusement, sous gnome (je ne sais pas quelle interface tu utilises) alt+F2 permet de lancer une commande, donc un autre terminal, par exemple, que celui qui plante, du genre xterm ou autre.
Si tu n’en as pas ou que tu ne te souviens plus du nom de ce que tu as pu installer, tu passes en console texte avec Ctrl+Alt+ F3 ou F4, tu te logues, et la tu pourras installer un terminal de rechange autre que celui que tu utilises habituellement (xterm par exemple).
Pour revenir en interface graphique, suivant, ça sera Alt+F7 ou alt+F1 ou F2, et là, tu pourras essayer de lancer le terminal que tu auras installé pour voir si ça te permet de débuguer ton terminal habituel en le lançant depuis un xterm.
Bon, j’ai ri avec la première phrase, mais pas à la première lecture!
je suis entré dans la console, réussi à me logguer avec root et un autre utilisateur mais pas avec le mien.
J’ai réinstallé xterm qui est installé (mais ne démarre pas) et je ne sais quelle autre console légère installer. Est-ce nécessaire si je me loggue en root dans la console? Je ne crois pas.
J’ai vu mais n’arrive pas à revoir une ligne qui dit failed et parle du maldet qui n’a pas démarré comme je le soupçonnais (maldet c’est le linux malware). J’essayerais alors de le tuer ou désinstaller? Il et visiblement lancé au démarrage puis perturbe le reste.
Si je comprends bien à ce stade:
- Je devrais trouver le log mais je ne sais comment
- désinstaller maldet mais vu que ce n’est pas un package debian j’ai peur de toucher et casser quelque chose
Merci de tes retours… Par contre je vais devoir partir et donc je suivrai les conseils mais pas tout de suite!
Tu dois pouvoir extraire les messages en console, en root, avec un grep maldet /var/log/syslog et éventuellement débuguer s’il y a bien des erreurs.
Ou bien tu peux essayer de désinstaller direct le paquet de ton machin maldet avec apt pour voir si ça répare, et on regardera dans les logs aprés pour le réinstaller, quand tu auras récupèré un terminal graphique.
C’est quoi le nom du paquet, je ne trouve rien dans les dépots buster.
C’est pénible, mais c’est intéressant pour comprendre ce qui ne va pas et ça peut donner une information sur ce qui plante.
Il y a plusieurs consoles, dont celle ou se lance l’interface graphique (souvent la 7, mais pas toujours) et tu peux passes de l’une à l’autre avec alt+FX (control en plus quand tu es en interface graphique.
Tu vas donc ouvrir une première session console, root de préférence pour éviter le sudo en permanence, et là tu met le log principal en suivi continu:
tail -qf /var/log/syslog
Ensuite tu passe sur une autre console, et tu essayes d’ouvrir une session avec ton user ou ça ne passait pas.
Vite aprés l’essai, tu retournes dans la console ou il y a le log sous surveillance, et tu regardes si il y a des messages d’erreur et si oui, tu les décris ici.
Ensuite, tu retournes en interface graphique, et tu essayes de lancer ton terminal qui plante.
Juste aprés, pareil, tu retournes dans la console avec le log sous surveillance, et tu regardes s’il donne des erreurs.
Salut,
Non, effectivement, tu peux très bien travailler sur une console ouverte avec Ctrl+Alt+Fn, et normalement quand tu auras réparé, xterm devrait se remettre à fonctionner.
Il y a peut-être quelques commandes console qui pourraient être utiles aussi :
ps ax | grep maldet
t’indiquera si un process nommé maldet tourne ou non ainsi que son PID qui te permettra de le killer au besoin (man kill). Tu as parlé de clamav également, tu peux donc aussi faire la même commande en remplaçant maldet par clamav.
top
te donnera un certain nombre de renseignements sur les process en cours, et te mettra en premier celui qui est le plus gourmand en ressources. Ça peut permettre de vérifier si, effectivement, un process (madet, clamav ou autre) semble monopoliser le proc ou la mémoire.
Je ne connais pas ton Linux Malware Detection (qui doit être écrit par µ$oft pour faire croire qu’il y a plus de malwares dans Linux que dans Windows 
), mais si tu vas voir dans /var/log et ses sous-répertoires, du devrais trouver ton bonheur… À condition que des logs soient bien générés, et pas dans un endroit exotique et farfelu (j’ai eu vu des cas…) !
Regarde déjà la doc : c’est peut-être bien indiqué (ça devrait, si ce n’est pas possible avec apt). Sinon, dis-nous au moins comment tu l’as installé (ou lien sur la doc).
Voilà quelques trucs qui me viennent à l’esprit pour compléter les judicieux conseils de @mattotop, mais il y en a d’autres… Dis-nous déjà ce que tu peux tirer de tout ça (qui, avec un tout petit peu de chance, devrait suffire à localiser le problème).
Il me semble que ceci est significatif quand j’ouvre mon user:
(root) CMD (/usr/local/maldetect/maldet --mkpubpaths >> /dev/null 2>&1)
Et quand j’ouvre (j’essaye) le terminal en mode graphique , je trouve comme plus significatif: gnome-terminal-server.service: Main process exited, code=killed, status=15/TERM
Je viens d’essayer mais ce processus est mouvant, comme clamav, il change de PID chaque fois.
top/htop ne m’indique pas de problème de mémoire.
Je viens de trouver l’instruction pour supprimer maldet avec un script qui était prévu. Après reboot, j’en suis à la même situation.
J’ai aussi supprimé et purgé clamav (apt --purge autoremove) et cela ne donne rien encore.
De temps en temps je me laisse convaincre de protéger mon système et ici cela me semblait très officiel (mais pas dans les paquets); c’est basé sur le moteur clamav.
Il doit être trés bien s’il est basé sur clamav, mais son install n’a pas du passer sous debian.
Je ne pense pas que ça ait été clamav, parcequ’il n’interfère pas directement avec les fichiers de l’espace utilisateur (sauf pour y scanner des virus quand on le demande).
Ou alors, si c’est clamav qui a fait quelque chose, ça peut être parce qu’un scan a détecté et mis en quarantaine un fichier, mais bon, j’ai des doutes.
Alors que maldet, on voit qu’il tape dans la gestion de la session utilisateur, sans doute pour intercepter le clipboard, ce genre de choses, donc j’imagine qu’il doit toucher aux scripts d’ouverture de session.
Tu as encore le répertoire /usr/local/maldetect avec peut être un truc qui traine dedans ?
Renomme le.
Sinon:
- est ce que tu ouvre une session avec ton user normal en mode texte maintenant ?
- si non, que dit /var/log/syslog à ce moment là ?
- idem quand tu essayes d’ouvrir un terminal graphique, que dit le syslog ?
Maldetect est complètement éliminé, y-compris le log
Voilà le log intégral (j’ai anonymisé le nom du PC, le user name et UID) quand je tente de me connecter en texte avec mon user (connect 2) puis tentative de lancer le terminal graphique (connect graph) comme tu l’as suggéré.
UserLog anonym.txt (4,7 Ko)
Attention qu’un process en cours capte et libère en permanence des ressources. Certains peu, mais certains beaucoup. Cela fait que l’affichage de top, surtout vers le haut, est très mouvant. Là-dessus, rien d’anormal.
Il peut y avoir un process qui se lance et se termine en permanence ou le temps de traiter tout ce qu’il y a à traiter. Ne connaissant pas maldet (et n’ayant pas pratiqué Clamav depuis bien longtemps), je ne sais pas si c’est normal ou non.
C’était une plaisanterie ! 
Pour la protection du système, il serait totalement faux de dire que Gnu/Linux est insensible aux malwares et autres virus. Mais sa conception robuste et la rapidité d’intervention des développeurs dès qu’ils détectent une faille de sécurité fait qu’un système à jour ne risque pratiquement rien. Par contre, ce qui risque, c’est les postes Windows du réseau : si un fichier vérolé se trouve sur un serveur Gnu/Linux, le serveur ne risque absolument rien, ni les autres postes Gnu/linux, mais les postes Windows qui y ont accès seront immédiatement contaminés. D’où l’utilité de clamav, que je n’utilise plus personnellement parce que je n’ai plus, depuis bien longtemps, de postes Windows dans mon réseau.
Pour ce fameux maldet, c’est probablement la même chose, mais ne connaissant pas je n’en dis pas plus.
Je vais essayer de me rappeler de cette explication sur les antivirus, je suis essentiellement sur mon pc et j’ai encore un vieux windows 7 (avec Avast) sur une partition que je n’utilise presque jamais.
Résumé de ma situation:
- j’ai viré clamav et maldet complètement en principe;
- sur ma session, je ne puis ouvrir de terminal (Ctrl T) et quand je passe sur les consoles (Ctrl Fx) je ne puis me logguer sur mon propre compte. Je puis me logguer en root ou avec un autre user.
- cela me semble complètement différent mais synaptic ne s’ouvre pas non plus en session graphique
- si j’ouvre une sesion (graphique) sur une autre user, CtrlT fonctionne très bien.
Il me semble moins certain que ça vienne d’une mauvaise install de maldet ou clamav, en fait:
ils étaient probablement correctement installés (je reviens sur ce que j’ai dit), mais ça ressemble plus à un fichier altéré par maldet ou clamav.
Il s’est passé je pense quelque chose sur tes fichiers de config utilisateur.
Regarde (avec ls -la pour voir les fichiers cachés les propriétaires et les droits) si tu n’as pas un fichier modifié récemment parmi les config, ou des droits bizarres (fichier appartenant à root ou quelqu’un d’autre dans ton /home/tonuser)
Autre épluchage/vérification:
zgrep maldet /var/log/syslog* dit quoi ?
Regarde s’il n’y a pas une mise en quarantaine d’un fichier de ton répertoire utilisateur.
Tu peux aussi tester la session utilisateur avec un répertoire perso vide:
Tu fermes toute session avec ton compte
depuis une autre, en root, tu renommes /home/tonuser /home/tonuser.bak,
tu recrées un répertoire vide /home/tonuser avec les mêmes droits et propriétaire
tu rouvres une session voir si ça marche et tu testes ton ctrl+T.
Si ça marche, on saura que le problème est dans le répertoire.
Ensuite, tu peux réintroduire 1 à 1 les fichiers de config (fichiers à la racine du répertoire user commençant par un . ) qui sont visibles seulement avec ls -a
Ou bien sinon, avec ton répertoire user en place, tu regardes les fichiers de config (ceux qui commencent par un modifiés récemment:
find /home/tonuser
Puis tu testes en remettant des backups de ces fichiers s’il y en a (finissant par ~, .bak, ou similaire).
Il ne reste plus que des lignes de la journée du 20 qui m’auraient peut-être guidé pour réparer (“maldet(751): {mon} could not find inotifywait command, install yum package inotify-tools or download from https://github.com/rvoicilas/inotify-tools/wiki/”).
De la date de ce jour, il n’y a plus rien.
J’ai trouvé et renommé un fichier /etc/default/maldet mais il ne contenait que des lignes commentées
Rien de particulier dans mon user…
Ne voyant rien dans les config, et ne voyant pas bien comment faire la manip avec les bakup de config, je suis un peu perdu…
C’est précisément ce que je cherche à voir, pour savoir ce qu’il a fait à ce moment là.
Je ne cherche pas les erreurs, ce sont les mise en quarantaine.
D’ailleurs, ça pourrait être intéressant de chercher aussi les messages de clamav.
Tu as donc regardé les dates de modification et tout est plus ancien que ton install de maldet ?
Et idem, tous les fichiers appartiennent bien à ton user, il n’y a rien qui appartienne à root ?
Tu es certain ?
Même dans les sous répertoires des répertoires à . comme .gconf, .kde, etc ?
Ultra simple:
- tu fermes toutes tes sessions sauf une en root (ou tu rebootes et tu te logues en root, c’est même mieux)
- tu executes
mv /home/tonuser /home/tonuser.bak
mkdir /home/tonuser
chown tonuser.tonuser /home/tonuser
chmod 0755 toto - aprés tu testes une connection graphique pour voir si tonuser marche quand tu fait Ctrl+T
Ca va te faire une session vierge non configurée dans ton nouveau répertoire home.
Et pour remettre ensuite comme avant, tu repasse avec seulement une session root, tu supprimes le répertoire home que tu as créé pour le test, et tu renommes celui que tu avais déplacé pour le remettre à sa place.
Pour moi tout à fait anodin, voici les deux recherches clamav et maldetzgrep clamav.txt (41,8 Ko) zgrep maldetect.txt (18,8 Ko)
Il y en a tant que ça que tu ne puisse pas copier coller dans le forum ?
Parce que là j’ai la flemme de cliquer et d’ouvrir des fichiers.
Heuuu je pensais que c’était plus sympa de ne pas noyer…
J’ai tout conservé et il y a 42000 caractères dans un premier fichier… donc on me le refuse, pas +de 32000
Ah OK, pardon.
Je n’avais pas fait attention aux tailles, et comme le premier plus haut était un fichier qui aurait aisément être copié, je ralais bêtement.
Je viens de re-revoir et non, rien dans .gconf, .gconfig, .gnome (pas de .kde)
Je vais alors me lancer dans la manip que tu proposes avec le changement de user