Nodemon: 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 [email protected] 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/remy/nodemon/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 https://github.com/remy/nodemon/issues/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!)

[KratosGemini]

@remy

1. I'm actually not seeing a slow restart time (unless it is on the order of multiple minutes). When it does pickup changes, it restarts quickly.
2. The higher CPU is not really a problem. My understanding is that higher CPU usage is expected when using the -L option. It's also not high enough to bog down my computer - it's just enough that I can see it.
3. Perhaps related to below.

Here is what I'm seeing. This is slightly updated with what I've actually discovered recently. I'm using nodemon with a Vagrant shared folder, and I'm editing the file on the host machine (nodemon is running on the guest). The only way I have gotten nodemon to _say_ it restarted on a file change is by starting it with the -L option. However, it only does so once. If I edit the file a second time, it will not _say_ it restarted. I've discovered that while it _says_ it restarted, it did not actually do so. The process running node is still running with the same PID, and the application does not show the updated behavior (from the file change). It appears that after one false positive restart when running the -L option, some process stops. I say this because CPU usage drops to almost nothing after the first "restart" (not that I'm saying the CPU usage was higher than expected), and I cannot get it to signal a restart again when editing the file.

In case it helps, I have been able to use supervisor (https://npmjs.org/package/supervisor) in this setup. It works as expected.

[mathroc]

Hi,

can it be related to difference in time between host and vm? I couldn't get it to work at first but after syncing time (ntpdate on both host and vm) it's now working? I guess that because timestamp are set form the clock of the machine writing into nfs

but there is still a ~2 seconds delay

what is nodemon doing to check status of a file when running with -L ? is it checking if file mtime is newer than 1 second?
if it's that, maybe an alternative would be to keep the mtime of each observed file and trigger a status change if the mtime changes

[remy]

@mathroc there's not a 1 second check. It's checked against the last time that nodemon started the child process: https://github.com/remy/nodemon/blob/master/lib/monitor/watch.js#L213

[mathroc]

oh yes, then it should only be a problem if there is a large difference between clock on host & vm

[remy]

@mathroc could that be it? Can you confirm your own VM & host and let me know? I was never really able to replicate when I use Vagrant, but it might be because my clocks are in sync.

[mathroc]

I just made a few tests:

• if host clock is ahead of vm (eg: 1min ahead), on file change, nodemon will keep restarting the process for 1 minute (because file mtime is 1 min in the future)
• if vm clock is ahead of host (eg: 1 min ahead), file changes are observed only after the process is at least 1 minute old. changes made before that are ignored because file mtime is still "older" than process start time

when nodemon is constantly restarting, I noticed it take it 2~4 seconds to do so:

vagrant on repository:develop ⚡ /usr/bin/nodemon -L --exec php -e 'php yml' -w app/config/ -w src/ -- app/console server:start --listen=tcp://127.0.0.1:9090
28 Jan 20:06:40 - [nodemon] v1.0.13
28 Jan 20:06:40 - [nodemon] to restart at any time, enter `rs`
28 Jan 20:06:40 - [nodemon] watching: app/config/**/* src/**/*
28 Jan 20:06:40 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`
server listening on tcp://127.0.0.1:9090
28 Jan 20:06:54 - [nodemon] restarting due to changes...
28 Jan 20:06:54 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`
server listening on tcp://127.0.0.1:9090
28 Jan 20:06:56 - [nodemon] restarting due to changes...
28 Jan 20:06:56 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`
server listening on tcp://127.0.0.1:9090
28 Jan 20:06:59 - [nodemon] restarting due to changes...
28 Jan 20:06:59 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`
server listening on tcp://127.0.0.1:9090
28 Jan 20:07:02 - [nodemon] restarting due to changes...
28 Jan 20:07:02 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`
server listening on tcp://127.0.0.1:9090
28 Jan 20:07:05 - [nodemon] restarting due to changes...
28 Jan 20:07:05 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`
server listening on tcp://127.0.0.1:9090
28 Jan 20:07:07 - [nodemon] restarting due to changes...
28 Jan 20:07:07 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`
server listening on tcp://127.0.0.1:9090
28 Jan 20:07:11 - [nodemon] restarting due to changes...
28 Jan 20:07:11 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`
server listening on tcp://127.0.0.1:9090
28 Jan 20:07:14 - [nodemon] restarting due to changes...
28 Jan 20:07:14 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`
server listening on tcp://127.0.0.1:9090
28 Jan 20:07:16 - [nodemon] restarting due to changes...
28 Jan 20:07:16 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`
server listening on tcp://127.0.0.1:9090
28 Jan 20:07:19 - [nodemon] restarting due to changes...
28 Jan 20:07:19 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`
server listening on tcp://127.0.0.1:9090
28 Jan 20:07:22 - [nodemon] restarting due to changes...
28 Jan 20:07:22 - [nodemon] starting `php app/console server:start --listen=tcp://127.0.0.1:9090`

but that was a small project (20 files in a few folders) and I don't think NFS is having performance issue:

vagrant at nopair on repository:develop ⚡ time (find src/ app/config/ | grep \\. | xargs ls -l > /dev/null)

real    0m0.020s
user    0m0.005s
sys     0m0.015s
vagrant at nopair on repository:develop ⚡ time (find src/ app/config/ | grep \\. | xargs cat > /dev/null)

real    0m0.041s
user    0m0.004s
sys     0m0.021s
vagrant at nopair on repository:develop

I might take a look at nodeman "-L" code but I don't have any knowledge about node libs, do you have any pointer to get me started on this subject?

[remy]

@mathroc if you re-run the test where it was restarting every few seconds, but add -V for verbose, it'll show what's triggering the restart.

The -L means that nodemon is checking the timestamps on the files on a regular interval (...though I'm double checking the code and I'm not sure it's doing that anymore. I did a bit refactor - because the code was confusing - and I think I might have factored that out...I'm double checking later this afternoon (have client work I need to complete this morning)).

Let me know how the first tests goes and I'll get back to you on -L.

[mathroc]

when it restart continuously, with -V, it showed which file triggered the restart, eg:

9 Feb 13:30:20 - [nodemon] starting `php app/console server:start nopair --listen=tcp://127.0.0.1:9090`
9 Feb 13:30:20 - [nodemon] child pid: 8737
server nopair listening on tcp://127.0.0.1:9090
9 Feb 13:30:35 - [nodemon] files triggering change check: app/config/config.yml, app/cache/dev/    appDevDebugProjectContainer.php, app/cache/dev/appDevDebugProjectContainer.php.meta
9 Feb 13:30:35 - [nodemon] matched rule: **/vagrant/app/config/**/*
9 Feb 13:30:35 - [nodemon] changes after filters (before/after): 3/1
9 Feb 13:30:35 - [nodemon] restarting due to changes...
9 Feb 13:30:35 - [nodemon] app/config/config.yml

9 Feb 13:30:35 - [nodemon] starting `php app/console server:start nopair --listen=tcp://127.0.0.1:9090`
9 Feb 13:30:35 - [nodemon] child pid: 8738
server nopair listening on tcp://127.0.0.1:9090
9 Feb 13:30:50 - [nodemon] files triggering change check: app/config/config.yml, app/cache/dev/    appDevDebugProjectContainer.php, app/cache/dev/appDevDebugProjectContainer.php.meta
9 Feb 13:30:50 - [nodemon] matched rule: **/vagrant/app/config/**/*
9 Feb 13:30:50 - [nodemon] changes after filters (before/after): 3/1
9 Feb 13:30:50 - [nodemon] restarting due to changes...
9 Feb 13:30:50 - [nodemon] app/config/config.yml

so the same file triggered the restart even if it was not modified, just because it's timestamp was far in the future

[chadkouse]

Chiming in with my experience...

-L seems to work -- but is painfully slow with my medium-sized project. Faster for me to just manually rs

I believe you are checking timestamps because i changed my clock (it was fast by over a minute) and nodemon continually restarted until the timestamp was in the past.

Host machine - mac OS X mavericks - vagrant running the precise32 box

[remy]

@chadkouse is there any way you can test with the clocks in sync? If it restarts quickly, then it confirms this - but then I'm not sure what the next step is...there's multiple ways that the monitor works, so off the top of my head I'm not sure what will change to makes this fly properly.

[chadkouse]

@remy so you want me to just start with my clock in sync and then just modify a file and see how long it takes nodemon -L to detect it and restart ?

[remy]

Yeah, in the hope that it's all good and then we try to solve how the
clocks are out of sync.

On Tuesday, February 18, 2014, chadkouse [email protected] wrote:

@remy https://github.com/remy so you want me to just start with my
clock in sync and then just modify a file and see how long it takes nodemon
-L to detect it and restart ?

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

-- Remy

[chadkouse]

@remy it seems to be working OK -- just a bit slow, but I guess that is to be expected with a medium sized project and legacy mode.

[remy]

@chadkouse how big is medium sized? (i.e. can you run find . | wc -l to count all the files being monitored?)

[chadkouse]

find . | wc -l
8625

find . | grep "\.js" | wc -l
2463

of those numbers about 1/2 of the files are in my node_modules folder which I can probably ignore

[honzajavorek]

I am also affected by this behavior with editing files on host machine and not having them reloaded on guest machine.

[dustMason]

+1 I'm also up against this issue. Same symptoms as described above. I'm happy to help debug, let me know what I can verify.

[colorfulgrayscale]

+1

Issue exists on OSX mavericks + Vagrant 1.6.0 + phusion/ubuntu-14.04-amd64

FYI: PM2's --watch seems to reload correctly.

[elado]

:+1:
Confirming that PM2 --watch works perfectly with --watch on Vagrant
https://github.com/unitech/pm2
Thanks @colorfulgrayscale

[freewil]

I recently ran into performance issues with trying to get autorestart working within Vagrant. I'm currently using forever --watch, but using NFS for shared folders produced a dramatic performance increase, and dramatically decreased the amount of time it took for the server to restart on a file change. See https://github.com/noplay/docker-osx/issues/60

[gkatsanos]

Just to say I have the same issue. MAC OSX (latest) host, Ubuntu 12.xx LTS Vagrant VM..
Nodemon takes 5-6" to pick up the changes, it's a pain if you need to work on SASS and wanna see your changes on the fly.. not sustainable :/ @guybowden , solved it somehow or ditched Vagrant:) ?

[j-carvalho]

I'm also having an issue with Vagrant and nodemon. It seems that the watch task only works with the -L flag, but for some reason it keeps detecting changes in the same file even though nothing changed. Was any one able to figure out the issue?

[samccone]

same setup as everyone here, and same issue. Let me know if I can be of any help to debug

[georgschlenkhoff]

+1 for that issue. Nodemon and Vagrant runs very unstable for my setting, too. Sometimes it works in legacy mode, '-L' option, plus explicit watching, '--watch /some_dir', and sometimes it just reloads every second.

I have tried to switch to another tool, such as PM2 or forever, but these tools seem to achieve different things than nodemon. For me: just restart server once I have saved my file in MacVim.

In the meantime I can live with 'rs' to restart server manually. But I am curious to know if there is any ongoing development with nodemon to support vagrant or if you guys have switched to another tool you'd recommend to me.

[gkatsanos]

I had to drop Vagrant completely and go native... can't work like that

[alejandronanez]

I had to drop Vagrant completely too.

[remy]

Is anyone able to try out the current version in this repo? It's not in npm
yet, but there are some fixes for virtual environments.
On 15 Jan 2015 14:05, "Alejandro Ñáñez Ortiz" [email protected]
wrote:

I had to drop Vagrant completely too.

—
Reply to this email directly or view it on GitHub
https://github.com/remy/nodemon/issues/146#issuecomment-70089032.

[georgschlenkhoff]

@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").

[georgschlenkhoff]

@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. :+1:

[georgschlenkhoff]

@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]

[email protected] 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 :closed_book:

[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

[georgschlenkhoff]

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" [e-mail] 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
https://github.com/remy/nodemon/issues/146#issuecomment-262613544, 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.

[Francesco-Rizzi]

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