Nodemon: Windows 10 Ubuntu Subsystem - Files not monitored

[nikitabe]

• Does the bug occur on latest nodemon? Not sure.
• nodemon -v: 1.14.1
• node -v: v6.1.0
• Operating system/terminal environment: Windows 10, Ubuntu Subsystem
• Command you ran: nodemon

Expected behaviour

Site reloads

Actual behaviour

No activity

Steps to reproduce

Run nodemon
Edited file using Visual Studio Code (located on /mnt/d/folder/folder/index.js)
Saved file

If, instead of using the Ubuntu subsystem, I use CMD, reload happens as expected.

[remy]

Can you provide a gist with a sample index.js and package.json and any nodemon configuration you're using?

Also, can you provide a screenshot of what you're seeing ideally with --verbose enabled.

Thanks in advance.

[remy]

@no-response that was way too quick! Reopening!

[remy]

@nikitabe ignore that this issue is closed, the bot is randomly aggressive with its closing (it was supposed to be 7 days!). Please go ahead and pop through more info so I can follow up.

[remy]

Can't replicate.

[nikitabe]

Remy, sorry for the delay. Here is a video of what's happening:

https://www.youtube.com/watch?v=3ZTpDNDAYfQ&feature=youtu.be

[remy]

@nikitabe can you run a new test (in the ubuntu subsystem) using nodemon --verbose and just record (in plain text is fine) the output when a file is changed. Does nodemon see the change, but decide not to restart, or does nodemon just miss it entirely (as it appears to from your video)?

[remy]

Just a thought, but does running nodemon -L work instead? (this is _legacy_ watch mode).

[YasharF]

@nikitabe just a quick check, are you on a Slow Ring release, or a Fast Ring release of Windows 10 by any chance, or are you on the latest production version of Fall Creator update (Windows 10 version 10.0.16299.125)? There are changes in WSL between different Win10 builds, which could help with figuring out how to replicate the problem.

[nikitabe]

@remy

nodemon -L - same problem
nodemon --verbose - looks like it's missing the change entirely

@YasharF Looks like Creator Update (Windows 10, Version 1709, OS Build 16299.125)

[remy]

I'm starting to run out of ideas here. If you try an entirely new project with a single file, I presume you get the same issue? (I'm asking because I can't replicate at all at my end…sorry).

Anyone else: can anyone else replicate this issue?

[YasharF]

A few things to do or check:

1. I noticed that your original post states there is a slightly older version of NodeJS 6.x on the system. Assuming that you can't upgrade to NodeJS 8.x, can you upgrade to the latest 6.x which is 6.12.2 right now in both Windows CMD and WSL and confirm the upgraded versions in both sides with node -v? https://nodejs.org/dist/latest-v6.x (the older versions also have a security issue)

In the CMD side, you probably need to download and install the MSI package, and in WSL:

$ sudo apt-get update && sudo apt-get -y upgrade
.....
$ node -v
v6.12.2
$ npm -v
3.10.10

1. Check global npm package versions npm list -g --depth=0 and upgrade nodemon to the latest version on both CMD and WSL by npm install nodemon -g in CMD (may need admin CMD) and sudo npm install nodemon -g in WSL.

2. Can you check if the WSL has been upgraded with the Fall Creator OS upgrade:

$ cat /proc/version
Linux version 4.4.0-43-Microsoft ([email protected]) (gcc version 5.4.0 (GCC) ) ...
$ cat /etc/issue
Ubuntu 16.04.3 LTS \n \l

1. Is the WSL from the Windows Store? In Windows (Explorer) verify that %localappdata%\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\ does exist and is not empty, while %localappdata%\Lxss does not exist. (Warning: do not manually modify files in those locations from Windows as it causes permission issues in the WSL side).

2. I noticed the video was on a path on your D drive. Can you check the partition types for the two drives? In my setup I have NTFS on two physical hard drives, and I get drvfs in WSL for /mnt/c and /mnt/d , and the problem didn't replicate.

$ df -Th
Filesystem     Type   Size  Used Avail Use% Mounted on
rootfs         lxfs   466G  394G   72G  85% /
none           tmpfs  466G  394G   72G  85% /dev
none           tmpfs  466G  394G   72G  85% /run
none           tmpfs  466G  394G   72G  85% /run/lock
none           tmpfs  466G  394G   72G  85% /run/shm
none           tmpfs  466G  394G   72G  85% /run/user
C:             drvfs  466G  394G   72G  85% /mnt/c
D:             drvfs  466G  458G  8.8G  99% /mnt/d

and in CMD (run as admin):

C:\>diskpart

Microsoft DiskPart version 10.0.16299.15

Copyright (C) Microsoft Corporation.
On computer: ....

DISKPART> list volume

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     E                       DVD-ROM         0 B  No Media
  Volume 1     D                NTFS   Partition    465 GB  Healthy
  Volume 2         System Rese  NTFS   Partition    100 MB  Healthy    System
  Volume 3     C   Windows      NTFS   Partition    465 GB  Healthy    Boot
  Volume 4                      NTFS   Partition    450 MB  Healthy    Hidden
  Volume 5     Q   Readyboost   exFAT  Removable   7437 MB  Healthy

1. After terminating nodemon in CMD, can you check in Windows Task Manager to see if there are any NodeJS or related processes still running? If there are any, can you check if manual termination of the processes in Task Manager makes a difference?

[remy]

@nikitabe did you get anywhere?

[remy]

@nikitabe I think I've inadvertently found the problem. Can you try with nodemon@debug - I _think_ the issue is that nodemon was silently breaking due to [email protected] not having support for stdio on the fork API.

I'm going to re-run my local test on windows, but instead of 6.x, I'll use 6.1.0 and see if I can replicate.

[remy]

I'm just posting an update. I'm now able to replicate, but this isn't a code issue - it's an OS issue.

I managed to replicate in this scenario:

1. Code and nodemon running inside of WSL (ubuntu 16, but I don't think this matters) using nodemon http.js
2. Importantly the directory the code is running on is inside my $HOME directory (in this particular case, ~/node-testing/http.js)
3. From Windows (not WSL), I open C:\Users\\AppData\Local\lxss\home\\node-testing\http.js in VS Code and make changes

My changes are completely ignored. I'm certain this is because I'm cross the OS system.

It does work when I edit files in the following directory: /mnt/c/Users/<username>/other-test-dir/ and then run the same command and same edit process.

I believe this is because the /mnt/ directory is mounted using some "special" flags (I'm fairly rusty on windows so I can't say exactly).

This is also supported by the fact that when I'm running nodemon inside of WSL, if I use vim to edit the file, it restarts as expected.

Long story short: a workaround is to use nodemon -L in WSL if you're editing in windows.