Importer service leaks into /tmp

[Robie Basak]

Currently when the systemd watchdog fires a worker does not clean up its files in /tmp. This leads to a disk leak except where PrivateTmp=yes is used when the service is run as a system systemd service. This is currently done, so this is now low priority. I'm filing the bug so we can track it in the long term.

Analysis

A worker calls the `scriptutils.import_srcpkg()` entry point. This is the same entry point as the previous `multiprocessing.map()` from `import-source-packages.py`. `import_srcpkg()` uses the `subprocess` module (via `gitubuntu.run`) to call `git ubuntu import ...`.

When the worker receives a SIGINT, it turns out that Python either terminates the subprocess with a SIGKILL immediately or it passes on the SIGINT and gives the subprocess a hardcoded 0.25 seconds before a subsequent SIGKILL. Details in [Python upstream issue 25942](https://bugs.python.org/issue25942). This isn't enough time to clean up a substantial `/tmp`.

Using subprocess is perhaps suboptimal anyway and we could move to calling a Pythonic entry point instead of using a separate process. We've slowly been moving towards that capability anyway. Risk: we may not have yet fixed every place this might break, for example the previous problematic pattern of using `sys.exit()`. Mitigation: this would just cause the worker to exit with an error status anyway; systemd could be arranged restart it and the broker will correctly treat it as a failure in the new concurrency architecture.

systemd's `PrivateTmp` works around the problem but is unfortunately not available for user instances. This is being used as a workaround by making the systemd services system instances.