Bug 251802 - security/clamav: unstoppable, unkillable clamscan process blocking system in state "ufs"
Summary: security/clamav: unstoppable, unkillable clamscan process blocking system in ...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Yasuhiro Kimura
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-13 11:50 UTC by O. Hartmann
Modified: 2021-12-14 01:49 UTC (History)
5 users (show)

See Also:
linimon: maintainer-feedback? (yasu)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2020-12-13 11:50:04 UTC

    
Comment 1 O. Hartmann 2020-12-13 12:03:06 UTC
OS: FreeBSD CURRENT (FreeBSD 13.0-CURRENT #168 r368515: Thu Dec 10 15:01:30 CET 2020 amd64), port clamav-0.103.0,1 and clamav-unofficial-sigs-7.0.1.

Roughly seven days ago the access to the hosts/netoworks providing clamav's update files were blockes by our firewall. Since 12th of December, clamscan is running with two instances for a user (myself) on the specified host and it is unkillable. I tried almost every KILL signal to stop the process as root, as the UID it runs as, with no success.

Opening files with vi doesn't work or starting a new screen with screen command (sysutils/screen, screen-4.8.0) is stuck forever - the attached tty is irresponsive, ssh sessions are stuck and stay in that state forever.

The problem looks like a full /tmp or /var/tmp filesystem, but there is plenty of space left and I can't see anything wrong with out of space or out of inodes.
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2020-12-13 18:04:56 UTC
^Triage: notify maintainer.
Comment 3 dewayne 2020-12-13 20:23:31 UTC
(In reply to O. Hartmann from comment #1)
Oliver, perhaps if you could kill the parent pid (kill -s KILL $PPID).  Examine 
ps -axwd -o pid,ppid,command
(Generally a SIGTERM should be all that's required, or per FreeBSD's shutdown sequence, finally a SIGKILL deals with the recalcitrant)

Also, don't rule out that you might have a full /tmp /var/tmp.  If an inode is being used, it may be locked to a naughty process and the space may appear free, but isn't.
Comment 4 Koichiro Iwao freebsd_committer freebsd_triage 2021-09-29 11:59:18 UTC
Assign to maintainer.
Comment 5 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-12-14 01:49:25 UTC
(In reply to O. Hartmann from comment #1)

Have you tried the advice in comment #3?