Je veux décharger les modules « gsch et redirfs » du noyau sur RHEL 7.2, ce qui provoque des panique du noyau.
Mais quand jessaye de décharger, jobtiens une erreur ci-dessous.
# modprobe -r gsch modprobe: FATAL: Module gsch is in use. # modprobe -r redirfs modprobe: FATAL: Module redirfs is in use. # lsmod | grep gsch gsch 88591 4 redirfs 79430 1 gsch
Comme coché, aucun processus contenant ces modules ,
# ps -ef | grep gsch root 26417 7838 0 10:58 pts/3 00:00:00 grep --color=auto gsch # lsof | grep gsch #
Commentaires
Réponse
Ces modules sont pour de vrai -time laccès aux fichiers du logiciel antivirus. À en juger par le nom « Trend Deep Security Agent » Trend Micro Antivirus, mais il pourrait en être un autre.
Réponse
Ce sont des modules de Trend Deep Security Agent:
# locate gsch /opt/ds_agent/2.6.32-431.el6.x86_64/gsch.ko /opt/ds_agent/2.6.32-431.el6.x86_64/gsch.ko.version /opt/ds_agent/2.6.32-642.3.1.el6.x86_64/gsch.ko /opt/ds_agent/2.6.32-642.3.1.el6.x86_64/gsch.ko.version # locate redirfs /opt/ds_agent/2.6.32-431.el6.x86_64/redirfs.ko /opt/ds_agent/2.6.32-642.3.1.el6.x86_64/redirfs.ko
Commentaires
- Autrement dit, lagent ds_agent doit dabord être arrêté avant de décharger les modules, oui?
lsmod
est le nombre de processus utilisant les modules. Vous ne verrez pas les modules comme des processus dansps -ef
ou comme des fichiers danslsof
car les modules sont du code du noyau compilé, et non des fichiers ou des processus par eux-mêmes . Le code du module est chargé en mémoire lorsque requis par un processus, et vous devez savoir ce que fait le module pour identifier quel processus peut lavoir chargé.dmesg
est probablement votre meilleur pari pour déterminer ce qui a provoqué le chargement du module.gsch
etredirfs
sont des modules propriétaires RHEL et pour obtenir des informations à leur sujet, vous avez besoin dun abonnement RHEL. Si vous avez un abonnement, la meilleure approche serait de contacter le support RHEL pour ce problème. Sinon, vous devriez attendre que quelquun ici qui connaît RHEL réponde ici.