Document in RTD that cloud-init users shouldn't write to /tmp due races with systemd LP:1707222

[Chad Smith]

Since cloud-init races with systemd cleanup of /tmp per LP: #1707222. We need to change doc examples which mention this issue when writing things to /tmp. We should also add a note or special consideration to cloud-init RTD about this case where pertinent so that users don't go down this route.
affects cloud-init 17.1

[Scott Moser (smoser)]

copied from https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/331736
for some background that would probably be useful to include or reference:

At first I was not keen on the use of /var/tmp, as I knew that Ubuntu was carrying a patch to systemd upstream for that behavior, and figured that we were really just buying time before someone decided "oh lets remove /var/tmp/ also".

I dug a bit, patch [1] that does this is to fix Debian bug 675422 [2].
That bug references the FHS [3] which at least gives us a reasonable justification for
our use:

| The /var/tmp directory is made available for programs that require
| temporary files or directories that are preserved between system
| reboots. Therefore, data stored in /var/tmp is more persistent than
| data in /tmp.

| Files and directories located in /var/tmp must not be deleted when the
| system is booted. Although data stored in /var/tmp is typically deleted
| in a site-specific manner, it is recommended that deletions occur at a
| less frequent interval than /tmp.

So, it seems sane that /var/tmp can be used.
But for some use cases /run/my-dir is better (in that it is guaranteed
to *not* have stale data across a boot).

[1] https://git.launchpad.net/~usd-import-team/ubuntu/+source/systemd/tree/debian/patches/debian/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch?h=applied/ubuntu/artful
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675422
[3] http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE

[Server Team CI bot (server-team-bot)]

This bug is fixed with commit 2e62cb8a to cloud-init on branch master.
To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=2e62cb8a

[Scott Moser (smoser)]

This bug is believed to be fixed in cloud-init in version 18.4. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3044