2

Apparently for months now, some process has been creating an empty .svg file in /tmp every minute and leaving it there. I now have 43,000 of these 262 byte files accumulated. I could just periodically delete them, but it'd be great if I could find the cause and even prevent it.

Does anyone know what this might be, or how to find out? I'd rather not try to figure out how to remount /tmp on a separate filesystem, like in this answer, and auditctl hasn't worked for me. Short of these methods, am I left with running lsof in a loop? It hasn't yielded anything yet.

Here's the contents of the .svg (it's always the same):

$ cat /tmp/tmpuo80js2t.svg
<?xml version="1.0" encoding="UTF-8"                         standalone="no"?><svg id="empty" xmlns="http://www.w3.org/2000/svg"                         height="22" width="1" version="1.0"                         xmlns:xlink="http://www.w3.org/1999/xlink"></svg>

Update: The filename pattern is /tmp/tmp????????.svg. Some examples:

/tmp/tmpsxzk1ktl.svg
/tmp/tmpti2by97z.svg
/tmp/tmp0woym_0_.svg
4
  • 1
    First thing comes to mind is to check if there's a pattern in the date of creation of a file. Then try to use one of the tools you've tried earlier at the time next file is created. – schrodigerscatcuriosity Jul 4 '19 at 19:03
  • is there a pattern to the file names? – jsotola Jul 4 '19 at 19:18
  • Hopefully you're running your tasks under non-privileged accounts. Does the owner of the files lend any clues to which process is creating them? – Jim L. Jul 4 '19 at 22:00
  • 1
    Can you upload the contents of ps -aux to pastebin? – cutrightjm Jul 5 '19 at 1:14
1

Okay, so it turns out I wasn't understanding auditctl correctly. I was able to use it to track down the culprit.

It turns out it was indicator-sysmonitor. It dies periodically on Ubuntu, so I'd wrapped it in a script which restarts it every minute. I assume it only creates this file on startup, and perhaps the way I kill it doesn't give it a chance to clean up. (I'll assume the error was on my part rather than it failing to clean up after itself.)

For posterity, here's how I tracked it down.

First, I started auditd watching /tmp:

$ sudo auditctl -w /tmp

Then, after it's been watching long enough to log the creation of one of the files, I picked the most recent one and searched the logs for it:

$ ls -lt /tmp/tmp*.svg | head -n 1
-rw------- 1 me me 262 Jul  5 13:42 /tmp/tmp4i0zh3mj.svg
$ ausearch -i -f /tmp/tmp4i0zh3mj.svg

The output contains a number of entries by several processes, but only one whose nametype is CREATE. The command (proctitle) of that one was /usr/bin/python3 /usr/bin/indicator-sysmonitor.

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.