Charge CPU 100%
Je suis sur un serveur linux debian. Depuis quelques jours, j'ai le message d'erreur suivant : CPU 100% utilisés / Processus 156.09 / Processus en veille 153.66.
J'ai réalisé un TOP et obtenu le résultat suivant :
- PID 14287 / USER root / PR 20 / NI 0 / VIRT 33224 / RES 4124 / SHR 1256 / S R / %CPU 99,6 / %MEN 0,1 / TIME+ 21454:11 / COMMAND packet
Pouvez vous me dire ce que cela signifie et comment je peux remédier à ce problème sans pertuber le serveur ?
6 réponses
Un serveur Debian affiche une utilisation CPU à 100% due au processus PID 14287 identifié comme 'packet' selon top, avec une consommation élevée et une activité continue. Plusieurs recommandent des vérifications comme ps -p 14287 -f et pstree -u -a -p pour confirmer le processus et examiner les connexions afin d’évaluer s’il s’agit d’une surcharge légitime ou d’activité suspecte. En cas de persistance, les conseils couvrent la mise à jour du système, l’arrêt ou le redémarrage des services, puis un audit des logs et du trafic pour identifier des activités anormales. D'autres éléments évoquent la vérification des commandes associées et la possibilité d'un spoofing du nom 'packet', ou d'une interprétation erronée du résultat.
-
ModérateurSalut,
Peut-être un Bitcoin...
Faudrait une capture d'écran et un pstree -u -a
Veuillez appuyer sur une touche pour continuer la désinfection... -
ContributeurSalut,
Que te retourne la commandeps -p 14287 -f
?
-
-
ContributeurSalut,
J'ai beau chercher sur le net, je ne trouve rien concernant le processus "packet" ;-\
Aucune trace non plus sur unedebian jessie
d'un quelconque paquetage nommé "packet".
J'ai bien unman packet
mais ça concerne les sockets :packet - Interface par paquet au niveau du périphérique
Reste plus qu'à tuer le processus en priant que ça ne casse rien ;-))
Attends quand même d'autres avis... -
@UnGnUMerci UnGnu.
J'avais également fait une recherche sans succès sur le net et c'est ce qui m'a fait poster.
Quand vous dites tuer le processus, cela consiste à faire quoi exactement ? -
-
@Utilisateur anonymeMerci Rocailleux
Je regarde cela demain. -
@MyMMSalut,
tuer le processus, cela consiste en quoi exactement ?
https://www.google.fr/search?q=tuer+le+processus&ie=utf-8&oe=utf-8&gws_rd=cr&ei=3AU-V4SoG9Oja6fXoLAO
Une petite recherche et hop, on a la réponse à ses questions kons.
-
-
Pouvez vous me dire ce que cela signifie et comment je peux remédier à ce problème sans pertuber le serveur ?
Même un reboot dans les heures de faible affluence n'est pas possible ?(4h par exemple)
J'aurai dit :
1 - Mettre à jour le système, ça vient peut-être d'un bug dans un des programmes qui a été corrigé depuis. Ça peut également servir à combler une potentielle faille qui aurait été utilisée pour lancer le processus génant
2 - Tuer les processus génants et redémarrer les services (ou reboot, plus radical)
Si le problème persiste repérer ce que fait le programme :
-analyse du réseau (wireshark/tcpdump), durcir les règles du pare-feu si possible.
-analyse du processus (recherche via la command lsof les fichiers ouverts par ce processus)
-faire un audit de sécu services, fouiner dans les logs pour chercher des activités suspectes-
-
Contributeur@Malekal_morte-
Ce serait bien aussi avec pstree de voir s'il y a un processus parent
Ben il semblerait que non ;-((

-
Modérateur@zipe31Ha..
Perso j'ai pas ce processus.
et cat /proc/PID/cmdline
ou ls -lh /proc/PID/exe
ça donne pas des infos ? -
-
@Flachy JoeBonjour,
Voici ce que me retourne le whereis packet :packet: /usr/share/man/man7/packet.7.gz
-
-
-
-
Contributeur@MyMMQue tu n'utilises pas Perl personnellement c'est un fait, par contre tout un tas de programmes peuvent faire appel à Perl dans leur routines.
D'ailleurs on voit dans ton arborescence une instance de Plesk (monitoring) et un gam_server. Rien ne nous dit que ces programmes n'utilisent pas Perl pour leur fonctionnement. -
-
Contributeur@Malekal_morte-En prévision… RKhunter ;-)
-
-
-



