Problems with unfs

[levinotik]

This may very well be an issue with the unfs native lib and not dinghy per se, but having some issues with dinghy up.

Waiting for NFS daemon...
/usr/local/Cellar/dinghy/3.0.2/cli/dinghy/unfs.rb:18:in `sleep': execution expired (Timeout::Error)
    from /usr/local/Cellar/dinghy/3.0.2/cli/dinghy/unfs.rb:18:in `block in wait_for_unfs'
    from /usr/local/Cellar/dinghy/3.0.2/cli/dinghy/unfs.rb:15:in `wait_for_unfs'
    from /usr/local/Cellar/dinghy/3.0.2/cli/dinghy/unfs.rb:11:in `up'
    from /usr/local/Cellar/dinghy/3.0.2/cli/cli.rb:34:in `up'
    from /usr/local/Cellar/dinghy/3.0.2/cli/thor/lib/thor/command.rb:27:in `run'
    from /usr/local/Cellar/dinghy/3.0.2/cli/thor/lib/thor/invocation.rb:126:in `invoke_command'
    from /usr/local/Cellar/dinghy/3.0.2/cli/thor/lib/thor.rb:359:in `dispatch'
    from /usr/local/Cellar/dinghy/3.0.2/cli/thor/lib/thor/base.rb:440:in `start'
    from /usr/local/bin/dinghy:5:in `<main>’

Any ideas? Thanks!

[levinotik]

I should that when initially installing, there were some issues with mismatched SHA1s on the unfs from sourceforge.

[codekitchen]

Yeah it looks like there is a problem starting unfs. You probably ran into #41 , unfortunately it's out of my hands. Waiting on an upstream fix.

[levinotik]

Arite, thanks @codekitchen

[codekitchen]

in the meantime I posted a workaround @ #41 (comment)

[jom]

I'm getting this too and have unfs v0.9.22 installed.

EDIT: a reboot fixed it for me

[codekitchen]

I've had another report of this, I agree that it doesn't look related to #41

We wait 20s for unfsd to start, which should be plenty long enough. I need to try and repro. Is there anything unfs-related in system logs (viewable in Console.app) when the error happens?

[johana-star]

In investigation with @codekitchen we found that this appears to be a launchd issue, but there wasn't significant details in the log to tell us where to dig next.

[twarlop]

@levinotik I had the same problem.
Apparently my brew was a bit messed up. and had a missing link on both unfs and dsnmasq
making brew doctor happy makes things running smooth now..

[rightjoin]

Same issue here

[codekitchen]

It might just be coincidence, but I had a co-worker who fixed this issue for him by installing the virtualbox expansion pack, which he didn't have installed yet. https://www.virtualbox.org/wiki/Downloads

[johana-star]

I resolved this with a reboot on my local machine, neglected to mention this in the above comment.

[rightjoin]

Had already tried the reboot. Just installed the extension pack too, but the problem persists.

[sja87]

same problem

fix it after downgrade 5.0.3 to 5.0 and NOT install Extension Pack

[rightjoin]

Naah, tried 5.0.0 as well, but the problem is still there

[codekitchen]

I wonder if this is related to the error this person saw #72 . If you run the nfs daemon manually, do you get a bind: Address already in use error?

You'll have to get the virtual interface host IP address to do that, basically run dinghy ip and replace the last portion with 1, so 192.168.99.100 -> 192.168.99.1

And then:

sudo /usr/local/sbin/unfsd -e ~/.dinghy/machine-nfs-exports-dinghy -n 19321 -m 19321 -l <ip_addr> -p -b -d

[lukebarton]

$ sudo /usr/local/sbin/unfsd -e ~/.dinghy/machine-nfs-exports-dinghy -n 19321 -m 19321 -l 192.168.99.1 -p -b -d
UNFS3 unfsd 0.9.22 (C) 2006, Pascal Schmidt <unfs3-server@ewetel.net>
bind: Address already in use
Couldn't bind to udp port 19321

[codekitchen]

Likely the same root issue then. I'd be very surprised if anything other than our unfsd process is binding to that UDP port on the virtual machine interface, so it seems likely to be an issue with another unfsd process already running, or something of that nature.

I would expect launchd to prevent this from happening, but maybe we're using it incorrectly.

[lukebarton]

Well, when I reboot, dinghy works fine the first time, second time it doesn't. So I'd fathom that it's dinghy's unfsd that's still running after not being shut down correctly.

[alex-kovshovik]

I finally got it to work locally:

• Deleted everything, including the dinghy VM.
• Downloaded the latest patch-level of VirtualBox and installed it.
• Downloaded the same version of VirtualBox Extension Pack and installed it.
• Ran dinghy create ...

I thought I did the same thing last time, but something must have been different.

[michaellopez]

@codekitchen My colleague ran into this issue too. We thought that upgrading VirtualBox and installing Extension pack was something to try but noticed after running dinghy halt && dinghy destroy we still saw dinghy running in ps. Reason we checked is that VirtualBox installer told us it found a running VM and refused to upgrade unless all VMs were stopped.

ps auxwww | grep VBox
<user>           17831   0.0  0.0  2465932    228   ??  S    10:31AM   0:00.02 /Applications/VirtualBox.app/Contents/MacOS/VBoxHeadless --comment dinghy --startvm 31a6077c-1cb8-4846-97fd-2b2b4c09c936 --vrde config

VirtualBox also did not have any dinghy machine in its list. So maybe this phantom VM is what is causing the binded port.

Killing that running dinghy vm process and upgrading VirtualBox did not fix it for him, but after a restart it did. So future people that may encounter this problem, please look for a rouge process and report it please :)

[codekitchen]

Yikes, seems worth filing an issue with VirtualBox as well.

[slwen]

Just for posterity, I was getting the same error when running dinghy up. I managed to get it working after trying to re-install Dinghy and finding that brew was unhappy and I needed to link unfs3

Ran brew link, and then finished a re-install of Dinghy, now everything is fine.

[codekitchen]

A lot of the issues with this are because launchd reports success even if the daemon fails to launch (apparently this is by design). Because of all the issues with using/abusing launchd the way we were, we've moved to our own daemon management code in the newest v4.1.0 release of dinghy. I'm going to close this, we'll handle any similar problems on the newest release as a new issue.