Usage with Vagrant

[guybowden]

Hi - I use Vagrant to set up a virtual machine to work from. When I update a file within my Mac IDE, nodemon doesn't detect the change. It detects the change if I call 'touch app.js' from within an SSH shell on the Vagrant machine however...

Any ideas?

[guybowden]

Seems that running it with the -L flag makes it work. Vagrant box is a clean Precise64 install by the way

[robwilkerson]

I have the same setup and, for whatever it's worth, the -L flag does seem to engage nodemon and get it to restart on changes, but it also seems to restart from time to time when there aren't changes. Or, since the restart is slow, maybe it's queuing up changes and if I :w multiple times it's just restarting once for each one and I'm getting ahead of the restarts.

[dankohn]

I have node running in a vagrant box with precise64. When using a Mac as host, nodemon -L takes ~4 seconds for a change to be noticed and a restart triggered. Unfortunately, with a Windows 7 host, nodemon -L is taking a minute or more to restart. I'm happy to share a test vagrant setup if you want to try debugging the problem.

[jonlil]

I'm using the same setup as @dankohn. Is there any method to make nodemon watching faster?
The 4 seconds delay is kind of annoying.

[remy]

Do you have an idea of how many files nodemon is checking against? When it's in legacy mode, it's manually going through every single file, calling fs.stat on the file, and checking the timestamp against the last time it ran - so big directories are going to get slow.

I don't know much about the performance inside of a Vagrant box, and I'm not totally sure why it needs to run in legacy mode (maybe the IO notify stuff doesn't work inside of Vagrant - I'm not sure), but that might be a cause.

If it's a windows box inside of Vagrant, it should be using fs.watch (and windows has the best implementation iirc), but nodemon has a lot of checks to work out which is the best watch method.

Is there a way to easily test this bug to help debug it? I'm hoping it doesn't include having to download a 7gb image file for Vagrant...!

[dankohn]

remy, thanks for responding. It definitely depends on your definition of easy. Are you willing to install VirtualBox and Vagrant (maybe ~150 MB) and then clone a git repository and type vagrant up. That should be all that's necessary, to test out the problem. I'll write up detailed steps (including links) to do so, if you will have time for it in the next week or two. For what it's worth, Vagrant is very popular (as is nodemon, obviously), so I think a lot of people would benefit from your debugging.

[remy]

Yeah, if you can write it up - then I'll follow that guide. I've used
Vagrant in the past to varying levels of success, and I don't have any
boxes that I can just bring up quickly (though I definitely have those two
installed).

Cheers,

• Remy

On 20 March 2013 15:47, Dan Kohn notifications@github.com wrote:

remy, thanks for responding. It definitely depends on your definition of
easy. Are you willing to install VirtualBox and Vagrant (maybe ~150 MB) and
then clone a git repository and type vagrant up. That should be all
that's necessary, to test out the problem. I'll write up detailed steps
(including links) to do so, if you will have time for it in the next week
or two. For what it's worth, Vagrant is very popular (as is nodemon,
obviously), so I think a lot of people would benefit from your debugging.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/146#issuecomment-15183823
.

[dankohn]

OK, here you go: https://github.com/dankohn/vagrant-nodemon

Please don't hesitate to ask questions about this vagrant setup (you can just post on this bug). I'm seeing pretty good performance with OS X (nodemon -L acts basically the same when run from the host or the guest). On Windows, I'm seeing a 1 minute or more delay. Do you have a Windows machine to test on? The only extra step is installing Putty to ssh to the vagrant virtual machine.

[remy]

@dankohn cheers for that - I've got a virtual machine with windows 7 I can test inside of.

I'll check that out when I get some time this week.

[antitoxic]

I seem to have problem with shared drive on plain VirtualBox - no vagrant. I couldn't find more related issue to post in and that's why I'm reporting here.

I can only get it to work with -L legacy option but as mentioned above it's slow.

EDIT: Running VirtualBox with ArchLinux in Windows 8 host.

[GeoffreyPlitt]

I'm using Vagrant as well, and for me, using the "-L" option makes it reload CONSTANTLY, over and over.

[GeoffreyPlitt]

Any ETA on fixing this? I'm about to move on to use another tool instead.

[remy]

@dankohn I finally got around to running these steps (annoyingly I did it on mac and not windows, so I need to repeat), but your repo says to run npm install but there's no package.json file).

[dankohn]

Sorry about that, I'll update it today.

[dankohn]

@remy it turns out that step wasn't necessary and so I've updated the Readme to remove it. Nothing else is changed so you don't have to re-pull.

https://github.com/dankohn/vagrant-nodemon

[mjackson]

I'm using Vagrant 1.2.2 running Ubuntu 12.04 inside VirtualBox 4.2.8.

I have the same problem with nodemon not picking up changes to the files that are being synced. I dug through the Vagrant source code and found that when using VirtualBox to host VMs, it uses the vboxsf command to mount shared folders.

There is a thread on StackOveflow that discusses using grunt (also a node program) to watch files inside a VirtualBox shared folder. There is some good feedback there.

For now the -L flag fixes the problem on my machine, but it is very CPU intensive even with just a few (< 20) .js files in the repo. Overall it looks like the problem may be with the way Vagrant is doing directory syncing in VirtualBox, and not so much a problem with nodemon.

[mjackson]

I just tried using Vagrant's NFS support and it seems to work a bit better than vboxsf. Unfortunately it still requires me to use the -L flag with nodemon in order to see changes. I don't get the crazy CPU spikes with NFS, but CPU usage is still higher than I'd like it to be. It used to spike up to 50-60%. It now hovers around 15-20%.

[mjackson]

This thread on StackOveflow makes it seem like nodemon could be improved if it watched files instead of directories.

@remy Would you be willing to consider watching individual files instead of directories?

[pasindud]

I think it is under consideration #155

[juggy]

I use brunch which uses https://github.com/paulmillr/chokidar to watch files under vagrant and the CPU is not going thru the roof as with nodemon.

Is it something you would be willing to try? I believe that chokidar uses the same api as fs.watch .

[remy]

Can someone with this issue try out the dev version? I found and squashed a bug that might be related to this slowness: npm install nodemon@dev

[KratosGemini]

I'm seeing the same behavior for nodemon v0.7.10 and v0.9.16. The only time I can get it to restart on a shared folder change is by running it with the -L option. Even with that option though it will only restart once (though it's fast to pick up the change). After the first restart, my CPU usage drops and it won't restart on another change. Given the drop in CPU usage, it seems like something is crashing...or at least stopping.

I've waited for it for over a minute for each try that failed. So if it is going to pick it up, it is very slow to do so.

Thanks for making nodemon, by the way. It's very useful.

[remy]

@KratosGemini can you try with the new version of nodemon: npm install -g nodemon@dev - it's close to 1.0.0 release, but trying to kill a few windows bugs.

[KratosGemini]

@remy I actually tried that earlier and got the same behavior as v0.7.10. I just tried npm install -g nodemon@dev again to make sure there wasn't a recent change. For me, it works the same as v0.7.10 for this test.

[remy]

@KratosGemini what version of @dev do you have? I've just pushed the most recent version - but suspect it won't make any difference.

[dalssoft]

I'm having this problem with nodemon@dev when I restart using "rs":

17 Dec 12:24:18 - [nodemon] v0.9.17
17 Dec 12:24:18 - [nodemon] to restart at any time, enter rs
17 Dec 12:24:18 - [nodemon] watching: /vagrant/server
17 Dec 12:24:18 - [nodemon] starting node index.js
Express app started on port 3000
rs
[nodemon] exception in nodemon killing node
[nodemon] Error: read ECONNRESET
at errnoException (net.js:901:11)
at Pipe.onread (net.js:556:19)

[nodemon] If appropriate, please file an error: http://github.com/remy/nodemon/issues/new

I tried @dev because the file change notification is not working for me as well.

Setup:
Vagrant 1.3.5
VirtualBox 4.3.2
Host: Mac OS - NFS
Guest: precise32
nodemon: 0.9.17

[KratosGemini]

@remy I upgraded to the latest dev (v0.9.17), and I see the same behavior.

[remy]

@dalssoft I think you're reporting a different issue. Are you saying that nodemon doesn't pick up on changes, or that it crashes when you type rs?

@KratosGemini can you quickly recap on the issue you're seeing - this thread is now covering 3 different issues: 1) slow restart time, 2) high cpu, 3) nodemon crashing (sorry, hard to keep track whilst trying to finalise the 1.0.0 release!)

[ghost]

@remy, great stuff!! I've

npm remove -g nodemon
npm install -g git+https://github.com/remy/nodemon.git

to get v1.3.0-5 and it seems to work!!

Though I've done just a rough smoke test, started with nodemon app.js (without -w or -L option) and saved three different files and nodemon did restart as expected.

Though I feel the starting up time is a bit slower than on my MacBook. But I think the reason for that is my memory constraints of my vagrant box, which is 2048 MB right now. What's your memory setting?

When you put new version to npm so we can npm install nodemon?

[remy]

@georgschlenkhoff that's great to hear. And yes, once it's stable and pushed, you can get it via a regular npm install (though nodemon also has an automate update notifier built in, which should "just work").

[ghost]

@remy, have another pro question: is there any chance to get nodemon with ec2 (aws-vagrant) workin'? that would be awesome to develop on a 244 GiB machine, ain't it? no more watin', no more ...

maybe it's a matter of configuring ports. i've tried it out, but nothing happens. which ports i have to activate, besides 22 (SSH) to get file watching working?

[remy]

@georgschlenkhoff what do you mean 'nothing works' - when you type nodemon nothing happens, or when a file changes nodemon doesn't see it?

[jtokoph]

@remy HEAD seems to be working properly for me on my ubuntu+virtualbox+vagrant combination. 👍

[ghost]

@remy: to be more specific, I have tried out nodemon on this vagrant setup. Nodemon does start up and serves the js files. But nodemon does not restart when I save a file on the editor on my local machine. I am not sure if it's a rsync issue with AWS.

@jtokoph: what you mean that ubuntu+virtualbox+vagrant is working for you? Does nodemon restart when you save a file on local machine? If yes, can I see your Vagrantfile?

[remy]

nodemon@1.3.x is now live.

This release also should address a bunch of VM issues - and where possible, nodemon will dynamically workout the time drift and compensate. If you're running a VM (i.e. Docker container) you'll see something like this (see virtual machine clock offset):

$ nodemon
9 Jan 22:41:30 - [nodemon] virtual machine clock offset: 15h46m53s
9 Jan 22:41:30 - [nodemon] v1.3.1
9 Jan 22:41:30 - [nodemon] to restart at any time, enter `rs`
9 Jan 22:41:30 - [nodemon] watching: four
9 Jan 22:41:30 - [nodemon] starting `node --harmony app.js`

Can I close this issue? :-\

[schinkowitch]

Working great on my vagrant set-up. Thanks!

[samccone]

thanks @remy all good to 📕

[IbnSaeed]

I am having the same issue of slow changes being reflected through the vagrant box running docker.

it takes around 2 to 3 seconds for the changes to show up. I am using nodemon 1.3.7

[ghost]

I am still not able to to get rsync working with nodemon. I'm using a Vagrant machine with AWS provider. Whenever I do any changes on local machine, nodemon does not restart. I'm not sure whether this is some Vagrant AWS Rsync specific issue. Maybe any other people got this setup working?

[IbnSaeed]

i just dropped nodemon for browersync and instant-server, both of which work extremely fast.

[kryz81]

the same problem with v.1.3.6 (vagrant with ubuntu on host and guest machine, shared folder),
nodemon doesn't see file changes,

debug:
3 Mar 11:06:28 - [nodemon] v1.3.6
3 Mar 11:06:28 - [nodemon] to restart at any time, enter rs
3 Mar 11:06:28 - [nodemon] watching: .
3 Mar 11:06:28 - [nodemon] starting node app.js --port=80 --dev --debug

[Jamesford]

I'm having the same problem with the following setup;

• Windows 8.1 (host)
• Ubuntu 14.04 (guest)
• Nodemon v1.3.7

Edit: Restarted host and it seems to be working now.

[kryz81]

with -L it works, but it's very slow

[mcharytoniuk]

It's a known Virtualbox issue (which is marked as WONTFIX): https://www.virtualbox.org/ticket/10660

If you use Vagrant with vmware software then there is a chance it will work correctly.

[AGhost-7]

I have an idea how to get this fixed, mind if I give this a try?

[sundayoyeniyi]

I am having this same problem with below set up

• host - mac os x
• guest - Ubuntu 14.04
• virtualisation - VirtualBox (5.0.10 r104061) + Vagrant (1.7.4)
• node - 4.2.4 LTS
• nodemon - 1.8.1

nodemon crashes / stopped watching for file changes after initial run, but nodemon -L options seems to be working fine.

Could this be a problem with the vagrant or with nodemon?

Thanks

SO

[voronkovich]

@sundayoyeniyi, try to use the rsync https://www.vagrantup.com/blog/feature-preview-vagrant-1-5-rsync.html

[sundayoyeniyi]

@voronkovich - thanks for your suggestion. the vagrant rsync approach solves the problem with gulp.watch tasks but Nodemon still crashes.

Thanks

SO

[voronkovich]

@sundayoyeniyi, if the nodemon stil crashes, I would suggest you to use https://github.com/fgnass/node-dev instead. I use it in my nodejs boilerplate: https://github.com/voronkovich/vagrant-nodejs-mongodb and it works fine.

[atesgoral]

For me, the -L flag was consuming too much CPU and Vagrant's rsync wasn't responsive enough. I ended up watching things on the host and remote-controlling Vagrant to restart the service. Full recipe here.

[Shaidar20]

Not to beat on a dead horse, but with nodemon version 1.11.0 it still does not work with the shared vagrant directory. The odd thing, is I'm not seeing a delay or high CPU utilization when using the -L option like everyone else is reporting. Granted, my node projects consist of 6 files so it does not have much to check.

Is this working better for anyone else?

[gkatsanos]

I already dropped both the stack and the hope to make it work in vagrant. The new fancy builders have their own servers for dev (like webpack dev server) and these things usually don't play nicely with vagrant)

…

On Nov 23, 2016 8:46 PM, "Shaidar20" ***@***.***> wrote: Not to beat on a dead horse, but with nodemon version 1.11.0 it still does not work with the shared vagrant directory. The odd thing, is I'm not seeing a delay or high CPU utilization when using the -L option like everyone else is reporting. Granted, my node projects consist of 6 files so it does not have much to check. Is this working better for anyone else? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#146 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABr9gtOSQeeQq5j_l94STmCzvzGVv7Crks5rBJgLgaJpZM4Aa1dg> .

[diegolorenzetti]

Try these mount options in your Vagrantfile:

type: "nfs", mount_options: ['actimeo=1']

This will greatly reduce the NFS file attribute caching timeout. Sometimes it can causes an error when try to save the file on your text editor, but it can solves the problem, at least for me works on my grunt watch task.

[0xFFrancesco]

Same here, Vagrant env, nodemon works only with the -L flag