Quick Tip On Shared Folders And Logging In Vagrant

Continuing with the recent posts on Vagrant, today, we’ll look at the tricky issue of shared folders and using them as locations to store logs.
My idea with using Vagrant was to keep all development-related files, including logs, on the host machine through shared folders, while the guest would only access these files through shared folders. This gives you the best of both worlds, as you can use your editor of choice on the host, while the files are executed on the guest. This works fine on a set-up that has only few shares and not more than port or two that are forwarded.
For a bit of background, this is how Vagrant goes through its start-up cycle.
First cycle is all network-related. It detects any forwarding conflicts, cleans up old forwarding settings and once the coast looks clear, it sets up all the forwards specified in the Vagrantfile.
Next cycle is the actual VM boot, where a headless instance of the VM is kicked into life.
Lastly, Vagrant loads all the shared folders.
The problem comes starts when the guest machine starts processing its init.d directives at the second cycle. The shared folders often take a good chunk of time to load, and depending on the level of panic triggered by the software started by init.d when it encounters missing files that are missing because, well, the shared folder that has them has not been shared yet, life may move on peacefully (with adequate warnings) or the software may just error out and die.
One such software is the Apache HTTPD daemon. It can start-up without issues if it can’t find the documents it has to serve, but it simply throws up its hands and quits if it can’t find the log files that it is supposed to write to. And a good developer always logs everything (as she/he should).
The solution, in the case of HTTPD, is to ensure that you log to a volume that is on the guest machine and not on the host. This does mean that you can’t tail the log file to see errors and requests stream by, from the host, but it is not a big problem compared to figuring out mysterious deaths of the HTTPD daemon, which starts-up fine after you do a ‘restart’ once the VM is fully up and running.