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. Commented Jul 4, 2019 at 19:03
  • is there a pattern to the file names? Commented Jul 4, 2019 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? Commented Jul 4, 2019 at 22:00
  • 1
    Can you upload the contents of ps -aux to pastebin? Commented Jul 5, 2019 at 1:14

1 Answer 1

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.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.