Whenever our A/V software tries to scan a large archive files(usually a tar.gz file > 1 G in size) the disk space for / partition increases drastically. How can we find out exactly where AV is putting the temporary files?

Once the scan completes, disk space drops back to normal. Since multiple users upload files simultaneously on this server(CentOS 6.8) with scans initiated automatically for each upload, disk space usage ramps up quite fast and at times reaches 100% for /.

I can see the disk increase in "df" but when I compare results of "du -ah --max-depth=1 /" for before and during the scan, I do not see a change for any of the folders.

enter image description here

Although, I do see Cache size increasing quite a bit using vmstat.

enter image description here

Tried checking for writes using "strace" and got multiple entries similar to the ones below. Not really sure how to interpret these.

9358  write(8, "x\3127\16|.b\245\342^\"\252\5X\323,\3036TP\225\33R_\206**\213\177\3405\250"..., 30720) = 30720
9358  write(8, "l\254\3239\335`\3\344\306w\35D~\227\271d\216\n\272\220\323\211\262\323\220\24\232M\221\305\202F"..., 30720) = 30720
9358  write(8, "\230}YI\324\317\201s\271z\245DJO\336u\225\213\22c\302zEW\270\320\322]WZQ\235"..., 30720) = 30720
9358  write(8, "\252\210H&]q\3309U!\207f\207o?\250l\215\332<\341\335h\245<8.\217\f\241\312C"..., 30720) = 30720


~ Abhi

  • lsof -p 9358 will show list of files opened by AV process. Alternatively, add -e open option to strace to trace attempts to open (and thus create) temporary file – myaut Feb 16 '17 at 19:08
  • Sounds like this antivirus needs to encounter r.zip – Joshua Jul 13 '17 at 16:20

The strace output shows you that 'write' is working on file handle 8. To work out what file handle 8 is you need to look at /proc/, in this case, /proc/9358/fd. 9358 is the PID that you were tracing and fd holds the open file descriptors for the PID.

You can see he current file descriptors for your running bash, if you look at:


So, if you do the above, you'll see 8 symlinked to the file that it is decompressing. If you need more time, then send a SIGSTOP to the A/V process whilst you do this work, then once you're happy you can SIGCONT the process so that it can continue with its work. Obviously, if this process is part of a network service, such as web/ftp/email, then you may not want to interrupt it as that might affect QoS for your users.

If you're lucky, you can probably do something like this, which saves you a bit of time from working out what the process ID is.

pkill -STOP -f 'av binary name'

There might even be a configuration file stored in /etc for your A/V software that might define a working directory.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.