remove /tmp cleanup command, fixes lvm rootfs

[ccope]

I left the following broken test until my question in #360 is answered:
Vagrant::LXC::Driver::CLI stop lxc-attach is not supported runs a /sbin/halt within the container

[fgrehm]

Hum... I'm not 100% sure we can do this.....

It has been a while since GH-68 (almost 2 years now 😲 ) but IIRC removing /tmp before the container is down resulted in a very bad side effect of losing my files synced folders mounted under that dir (like puppet manifests).

Dunno if that still holds (neither if we need to keep this "cleanup behavior" around from within the plugin's core), but it might be worth testing.

[ccope]

mounting stuff in /tmp doesn't sound like the greatest idea :-\

[fgrehm]

But that's the default Vagrant behavior =/

[fgrehm]

Oh, and vagrant-cachier does that too!

[ccope]

I'm digging into why this doesn't just work now. Looks like there's a script that's supposed to run when /tmp gets mounted (on Ubuntu, at least). Do we know if any distros besides Ubuntu and Debian were affected? What was the impact of not cleaning /tmp?

[ccope]

Also, I just tested this with the download template image for ubuntu 12.04 and 14.04, and /tmp was correctly cleared.

[ccope]

...oof. I dug deep, and figured out why this is an issue for vagrant-lxc and not other providers. Those init scripts that clean /tmp aren't supposed to delete data on other filesystems. However, lxc uses bind mounts for directories on the same filesystem, so find -xdev doesn't think they're on a different filesystem. So.... mounting stuff in /tmp is bad....

[fgrehm]

Do we know if any distros besides Ubuntu and Debian were affected? What was the impact of not cleaning /tmp?

I only remember experiencing that on some old Debian box. It was Wheezy IIRC and it was from "pre-download template" ages, but can't say for sure.

mounting stuff in /tmp is bad....

It has been a loooong time since I used Puppet / Chef so I might be wrong on this but isn't the default behavior for those provisioners to mount their manifests on /tmp by default when used from Vagrant?

[ccope]

Bleh, yep. Still doesn't make it right :-\ If we could mount those directories as read-only in the container, we could probably avoid this issue. Any ideas on whether it would be feasible to catch all mounts in /tmp and force them to be read-only?

[ccope]

Ok, I looked through the code more and I think it's fairly easy to force all /tmp mounts to be read-only. Here are the options I see, in order of preference:

1. Just leave cruft in /tmp (I still don't know what problems this causes, if any)
2. Force all mounts in /tmp to be read-only
3. Throw an error if the user mounts anything non-readonly in /tmp with the 'dir' or 'none' backingstores
4. Add/modify init scripts in every base box to umount /tmp mounts before halting (distro/init system dependent 😞 )

I also thought about using attach commands to do this in a distro-agnostic way, but that doesn't cover if the user runs halt/lxc-stop manually. Also, for what it's worth, it seems like the image from the LXC 'download' template doesn't run the init script for cleaning /tmp (tested with -d ubuntu -r trusty).

[fgrehm]

Just leave cruft in /tmp (I still don't know what problems this causes, if any)

I also can't remember a problem this might cause but I still think it is a nice to have around. If making the mounts read only allow us to keep that behavior around I'd lean towards that, otherwise lets just remove this behavior.

If someone else happens to be watching the project has strong opinions about removing this behavior please let us know!

[fpletz]

Couldn't we just mount a tmpfs over /tmp to fix this?

[ccope]

Hmm, yeah that would probably work if we can ensure the mounts get ordered correctly.

[ccope]

Ok, so since this solution doesn't require attach to work any more, I've held off on deprecating LXC < 1.0.0. @fpletz does this look good to you?

[fpletz]

Thanks, looking good! 👍