That is unexpected.

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

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 :)

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?

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 :)

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

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

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
})

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.

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

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

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

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

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.

Increasing the inotify watches worked! ty!

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