Chcę wyładować moduły „gsch and redirfs” z jądra na RHEL 7.2, co jest częste panika jądra.
Ale kiedy próbuję wyładować, pojawia się błąd poniżej.
# 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
Jak zaznaczono, żadne procesy nie przechowują tych modułów ,
# ps -ef | grep gsch root 26417 7838 0 10:58 pts/3 00:00:00 grep --color=auto gsch # lsof | grep gsch #
Komentarze
Odpowiedź
Te moduły są prawdziwe -czasowy dostęp do plików oprogramowania antywirusowego. Sądząc po nazwie „Trend Deep Security Agent” Trend Micro Antivirus, ale mógłby być inny.
Odpowiedź
To są moduły z Agent Trend Deep Security:
# 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
Komentarze
- Oznacza to, że ds_agent należy najpierw zatrzymać przed wyładowaniem modułów, tak?
lsmod
zawiera liczbę procesów wykorzystujących moduły. Nie zobaczysz modułów jako procesów wps -ef
ani jako plików wlsof
, ponieważ moduły są skompilowanym kodem jądra, a nie plikami lub procesami samodzielnie . Kod modułu jest ładowany do pamięci, gdy jest potrzebny procesowi, i musisz wiedzieć, co robi moduł, aby zidentyfikować, który proces mógł go załadować.dmesg
to prawdopodobnie najlepszy sposób na ustalenie, co spowodowało załadowanie modułu.gsch
iredirfs
są zastrzeżonymi modułami RHEL i aby uzyskać informacje o nich, potrzebujesz subskrypcji RHEL. Jeśli masz subskrypcję, najlepszym rozwiązaniem byłoby skontaktowanie się z pomocą techniczną RHEL w tej sprawie. Jeśli nie, powinieneś poczekać, aż ktoś tutaj, kto wie o RHEL, odpowie tutaj.