"vagrant up" stays running in the background

265 views
Skip to first unread message

Amos S

unread,
Jul 1, 2015, 7:44:43 PM7/1/15
to vagra...@googlegroups.com
Environment:
OSX 10.10.3 (10.10.4 upgrade waiting for reboot)
Vagrant 1.7.2 installed from .dmg
VirtualBox 4.3.28r100309

I've been bringing up Ubuntu 12.04.5 LTS boxes for a while. Provisioned using Puppet and tested with vagrant-serverspec.

After the box is brought up fine I find that the "vagrant up" process is still running a child process:

$ ps -ef | fgrep vagrant
  501 47041     1   0  8:46am ??         0:00.13 ruby /opt/vagrant/bin/../embedded/gems/gems/vagrant-1.7.2/bin/vagrant up --color all.ubuntu-safeshare.dev

As you can see, the parent of this process is not my shell but init.
The Puppet provisioner passes fine, the "serverspec" provisioner fails a couple of tests because it doesn't wait enough, but otherwise it exits.
The process holds the lock on the Vagrant box so I can't re-provision it (e.g. to rerun tests) until I kill it.
A simple "kill 47041" is enough.
The process doesn't have any children (according to "pstree", and it doesn't output anything to its stdout or stderr.

This is the list of installed plugins:
$ vagrant plugin list
landrush (0.18.0)
vagrant-cachier (1.2.0)
vagrant-host-shell (0.0.4)
vagrant-serverspec (1.0.1)
vagrant-share (1.1.3, system)

I manage to get the same behaviour even with "--no-provision" flag, which might rule out any provisioner interfering.

If I look for processes while "vagrant up --no-provision" is running I see two processes pretty much all the time, one of them has init (pid 1) as its parent all this time too, then the parent (the direct bash child) exits but the other process stays behind and holds the lock.

From looking at the "--debug" output, it seems that all the external commands executed by Vagrant are VBoxManager, could this be a VirtualBox bug?

Thanks.

Alvaro Miranda Aguilera

unread,
Jul 1, 2015, 7:48:25 PM7/1/15
to vagra...@googlegroups.com
any chance for the reboot on your host and check if the issue remains?
> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/mitchellh/vagrant/issues
> IRC: #vagrant on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vagrant" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vagrant-up+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vagrant-up/fba5546a-1dd1-4caa-ba9d-39bfb8aed2fe%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Amos S

unread,
Jul 1, 2015, 9:18:35 PM7/1/15
to vagra...@googlegroups.com
On Thursday, 2 July 2015 09:48:25 UTC+10, Alvaro Miranda Aguilera wrote:
any chance for the reboot on your host and check if the issue remains?

Done. Still same issue.

I also tried to trace through the fork's/exec's of Vagrant but dtrace wasn't completely cooperative,
for instance I don't see any explicit "exec" system calls in the dtrace output, and the PID of the process
left behind is never returned by any of the "forks" (perhaps it's done by an suid binary which conceals
this from dtrace?)

I had to run Vagrant as my own user under dtrace, this is how I did that:

$ sudo dtruss -f sudo -u $USER vagrant up --no-provision --debug --color vagrantboxname

Without the second "sudo -u $USER" vagrant exits without doing anything.

Bottom line - still no progress.

Amos S

unread,
Jul 2, 2015, 10:34:00 PM7/2/15
to vagra...@googlegroups.com
After more investigation, I think the issue is that I use landrush (https://github.com/phinze/landrush) and perhaps also
that landrush has a problem logging in to our custom basebox.
Landrush does have an open issue similar to my problem: https://github.com/phinze/landrush/issues/104
Reply all
Reply to author
Forward
0 new messages