Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

filepath.Walk() no space left on device #23

Closed
cameracker opened this issue Jan 25, 2017 · 15 comments
Closed

filepath.Walk() no space left on device #23

cameracker opened this issue Jan 25, 2017 · 15 comments

Comments

@cameracker
Copy link

cameracker commented Jan 25, 2017

I get this every time I try to run compile daemon.

Any advice?

Thanks.

@githubnemo
Copy link
Owner

githubnemo commented Jan 26, 2017

That is unexpected.

Any special things concerning your environment? OS? What file system are you using?

@cameracker
Copy link
Author

Sorry for the delay.

After a few reboots and such I determined that running the command in visual studio code's integrated terminal causes this problem, and in some unknown cases can cause CompileDaemon to yield this error until reboot. I'm not sure what about VSC causes the error, or why it is permanent sometimes but I think it can be worked around by simply not running it in VSC :)

@githubnemo
Copy link
Owner

Well, that's odd.

So I assume you are starting CompileDaemon more than once in the VSC terminal? Because Walk() is only called once at the beginning. Maybe there are other instances of CompileDaemon lingering in the background, eating up all free file descriptors and at the end, Walk() in the new instance cannot open any more files?

@cameracker
Copy link
Author

In this case we only use CompileDaemon for one specific component of our software and only use it there. So there should have only been one instance.

I suspected that there was a lingering instance initially, but couldn't find evidence of that using ps or any other task manager. And it doesn't explain why after a reboot ->VSC start it'd be busted. I'll keep poking at it and will share anything interesting I find, but I don't know if there's anything in particular to figure out.

Thanks for paying attention to this :)

@robbert229
Copy link

Encountered the same issue on a fresh reboot. Not using VSCode but I am using Atom.

@githubnemo
Copy link
Owner

@robbert229 any infos on the environment you are using? How do you invoke CD?

@robbert229
Copy link

I am running Arch Linux, and I was attempting to invoke

CompileDaemon -exclude-dir=./minio-data -exclude-dir=./neo4j-data -color -build="go build -o api.exe server" -command="npm run api" -graceful-kill=true -log-prefix=false

Edit

Found the solution! It turns out that -exclude-dir wouldn't exclude the desired directories, this is because of the ./ prefixing the directory name.The flag -exclude-dir=./vendor wouldn't ignore the vendor directory

Will looking through the source for the cause of my problems I saw that filepath.Walk had somthing interesting in it. info.Name() returns the name of the file. If it was walking over ./vendor/aws/foo.go it would be foo.go, is this intended behavior?

err = filepath.Walk(*flag_directory, func(path string, info os.FileInfo, err error) error {
	if err == nil && info.IsDir() {

		if flag_excludedDirs.Matches(info.Name()) {
			return filepath.SkipDir
		} else {
			fmt.Printf("Adding: %s\n", path)
			return watcher.Add(path)
		}
	}
	return err
})

@githubnemo
Copy link
Owner

This problem would be detected earlier if CD had a verbose mode, plotting the watched directories. Good job at identifying the problem, I haven't looked into it yet but this looks promising. I will look into this momentarily.

@githubnemo
Copy link
Owner

githubnemo commented Mar 8, 2017

@robbert229 thanks for finding the actual issue behind this problem! It should be fixed now.

@mrosentr
Copy link

I still have this issue with Ubuntu 16.04 64bit after recompiling fix#23.

@githubnemo
Copy link
Owner

@mrosentr Can you paste the command line of how you invoke CD and the output when starting with -verbose?

@mrosentr
Copy link

I use this one primarily:
CompileDaemon -directory=. -build="go build -o server" -command="./server" -color=true -verbose

Have also tried this:
CompileDaemon -directory=/path-to-source -build="go build -o server" -command="./server" -color=true -verbose

Output:
2017/03/15 14:22:17 Watching directory '.' for changes.
2017/03/15 14:22:17 filepath.Walk():no space left on device

@githubnemo
Copy link
Owner

A gotcha. This is from fsnotify.Watcher.Add() which roughly translates to the inotify_add_watch syscall which describes the failure mode ESPC as follows:

ENOSPC The user limit on  the  total  number  of  inotify  watches  was
        reached or the kernel failed to allocate a needed resource.

Consider increasing the number of possible inotify watches.

@mrosentr
Copy link

Increasing the inotify watches worked! ty!

@sevkin
Copy link

sevkin commented Aug 7, 2017

@githubnemo plz add solution about fs.inotify.max_user_watches in notes section of readme

githubnemo pushed a commit that referenced this issue Oct 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants