linux abrtd est un démon qui surveille les plantages d'applications ; lorsqu'un crash se produit, il collectera l'application en panne et prendra des mesures en fonction du type de crash configuré dans le fichier de configuration abrt.conf, situé dans le dossier "/etc/abrt". répertoire Il y a sa configuration "abrt.conf" et ainsi de suite.
L'environnement d'exploitation de ce tutoriel : système linux5.9.8, ordinateur Dell G3.
Le service abrtd occupe les ressources du système ?
Il existe un processus dans notre environnement de développement qui consomme particulièrement des ressources. Cela s'est déjà produit plusieurs fois sur site et dans le cloud public. Finalement, ce processus remplira la mémoire de la machine et entraînera des temps d'arrêt. Maintenant, je viens de découvrir ce problème sur place
La première chose à faire lorsque le processus est plein est de regarder le nom du processus et de vérifier visuellement qu'il est terminé. la première fois que je l'ai vu
top -pH 48297 Jetez un œil au thread du processus spécifique qui a un problème et constatez qu'un seul processus n'a pas de thread
ps Regardez où se trouve le répertoire de ce service
[root@yq01-kg-section1-bud3 libexec]# ps -ef | grep abrt-hook-ccpp root 45733 11797 0 12:18 pts/8 00:00:00 grep --color=auto abrt-hook-ccpp root 48297 2 99 Nov16 ? 15:42:50 /usr/libexec/abrt-hook-ccpp 11 0 8669 0 0 1605530067 e 8669 8669
Aucune idée ! ! J'ai commencé à chercher sur Baidu et j'ai trouvé ce qui suit
abrtd est un processus démon qui surveille les crashs d'applications. Lorsqu'un crash se produit, il collectera l'application crash (ligne de commande des fichiers principaux, etc.) et la prendra. mesures en fonction du type Le crash se produit et est basé sur la configuration dans le fichier de configuration abrt.conf. Il existe différentes actions du plug-in : par exemple, bugzilla signale un crash, transfère le rapport via FTP ou report ou scp. consultez la page de manuel du plug-in correspondant.
abrtd : démon de rapport de bug automatique
Lors du débogage d'un programme Linux, le plus pénible est que le programme plante anormalement, mais le fichier core est introuvable, ce qui rend difficile la localisation du problème. Mais avec le fichier core, il est beaucoup plus facile à localiser.
Généralement, vous pouvez définir ulimit -c unlimited dans la variable d'environnement. Mais les responsables de la mise en œuvre sur le terrain oublient parfois de définir cette commande. Alors que faire ? Cela peut être réalisé en configurant le service abrt de Linux.
Modifiez le fichier abrt-action-save-package-data.conf
Modifiez-le pour :
vi /etc/abrt/abrt-action-save-package-data.conf # With this option set to "yes", # only crashes in signed packages will be analyzed. # the list of public keys used to check the signature is # in the file gpg_keys # OpenGPGCheck = no # Blacklisted packages # BlackList = nspluginwrapper, valgrind, strace, mono-core # Process crashes in executables which do not belong to any package? # ProcessUnpackaged = yes # Blacklisted executable paths (shell patterns) # BlackListedPaths = /usr/share/doc/, /example*, /usr/bin/nspluginviewer, /usr/lib/xulrunner-*/plugin-container 还可以调整core文件的大小: [root@xx-host2 abrt]# cat abrt.conf # Enable this if you want abrtd to auto-unpack crashdump tarballs which appear # in this directory (for example, uploaded via ftp, scp etc). # Note: you must ensure that whatever directory you specify here exists # and is writable for abrtd. abrtd will not create it automatically. # #WatchCrashdumpArchiveDir = /var/spool/abrt-upload # Max size for crash storage [MiB] or 0 for unlimited # MaxCrashReportsSize = 1000 # Specify where you want to store coredumps and all files which are needed for # reporting. (default:/var/spool/abrt) # # Changing dump location could cause problems with SELinux. See man abrt_selinux(8). # #DumpLocation = /var/spool/abrt # If you want to automatically clean the upload directory you have to tweak the # selinux policy. # DeleteUploaded = no
Redémarrez le service abrtd : service abrtd restart
Si vous avez un fichier principal, vous devez le supprimer à temps. le fichier via le package abrt-cli list, puis utilisez abrt-cli rm [package de fichiers].
Lorsque le programme plante, abrt-hook-ccpp utilise trop de CPU et les E/S sont trop élevées, ce qui provoque la saturation du système. Désactivez-le simplement
systemctl stop abrt-ccpp.service
systemctl désactiver abrt-ccpp.service
. systemctl status abrt-ccpp.service
J'ai vérifié systemctl status abrt-ccpp.service et j'ai constaté que ce service n'est pas démarré du tout
Baidu encore une fois
usr/libexec/abrt-hook-ccpp Pourquoi ce processus continue-t-il d'augmenter ? Parce que ce n'est pas possible. Le
sed -i 's/ProcessUnpackaged = no/ProcessUnpackaged = yes/g' /etc/abrt/abrt-action-save-package-data.conf&& service abrtd restart
Nov 17 13:15:15 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297 Nov 17 13:15:15 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297 Nov 17 13:15:16 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297 Nov 17 13:15:16 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297 Nov 17 13:15:17 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297 Nov 17 13:15:17 yq01-kg-section1-bud3 systemd: abrtd.service stop-sigterm timed out. Killing. Nov 17 13:15:17 yq01-kg-section1-bud3 systemd: abrtd.service: main process exited, code=killed, status=9/KILL Nov 17 13:15:17 yq01-kg-section1-bud3 systemd: Unit abrtd.service entered failed state. Nov 17 13:15:17 yq01-kg-section1-bud3 systemd: abrtd.service failed. Nov 17 13:15:17 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297
kill -9 48297
Vérifiez l'état du service
Tutoriel vidéo Linux"
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!