Adventures in Vagrant: tee
I am sharing another adventure in working with provisioning in
Vagrant. I will go over a time where I debugged a slow nodejs
installation and found a better way to collect screen output using
If this article improves the way you work with the vagrant provisioner
or any other UNIX command, then I have done my job. Using
help debug provisioning delay and/or errors by combing through files
instead of screen output. This article will take less than four
minutes of your time, probably less because there’s console output.
From my last
nvm to manage node, so the provisioning script would run
to install node (
The installation progress stalled at 50% for a long time. I was kind of wondering: “Why?” and just assumed it was Wi-Fi. When a coworker saw the same thing on the company Internet connection, that made me think: “There is something going on here.”
tmux to the Rescue
tmux, I was able to review the Vagrant provisioner output
This made think: Wow, two cores is not enough?! I decided: let’s add CPU cores to the virtual machine!
More CPU cores - faster downloads?!
The next time I ran the provisioner, there was no problem and downloaded immediately. Easy peasy!
This made me think: what else is happening in Vagrant provisioning stage that I am not catching??
Catching error Sooner?
One reason I’m not catching these errors: I can’t scroll back that far, especially as long output happens. When node installs, it’s verbose:
I tune out when there is this amount of output and not at the computer
I was only able to catch the problem thanks to
tmux. Are there
- Does nvm have a
- Does keep_color option help preserve line formatting? nope.
- Can I redirect output to a file (for later inspection)? MAYBE
Redirecting output: Using
>> to redirect all output
vagrant up > vagrant_up.log) works, there’s no output to the
screen. When there’s no output, is the provisioning step moving along
or just stuck at 50%?
Having the provisioner output to the screen is important feedback,
it’s definitely needed. Ironically, I may or may not be at the
vagrant up is showing this feedback.
Welcome my new friend:
If everything goes well, remove the vagrant_up.log file, if something doesn’t go well, I can see it on screen AND comb through the vagrant_up.log file for errors and notifications, such as not enough CPU cores.
Vagrant’s provisioner is fantastic in creating custom virtual machines. Its output can be verbose and hide errors in its process.
I was lucky this time
tmux captured the output, or I would have a
slow nodejs installation every time.
Instead of trying to be lucky or attend every provisioning step, I looked for a better solution.
Trying to find a better solution,
tee, to solve a simple problem has
led me to another UNIX utility that I can use more often.
vagrant up, it can help you debug your provisioning
vagrant up | tee vagrant_up.log