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

watch with lots of files dies #168

Closed
philips opened this issue Jan 12, 2014 · 26 comments
Closed

watch with lots of files dies #168

philips opened this issue Jan 12, 2014 · 26 comments

Comments

@philips
Copy link
Contributor

philips commented Jan 12, 2014

$ find . -type f | wc -l
    8149
29 pages created
0 tags index created
1 topics index created
in 37 ms
Watching for changes in /Users/philips/trees/ifup-hugo/content
Web Server is available at http://localhost:1313
Press ctrl+c to stop
panic: listen tcp :1313: too many open files

goroutine 27 [running]:
runtime.panic(0x3d2a20, 0x210b68240)
    /usr/local/go/src/pkg/runtime/panic.c:266 +0xb6
github.com/spf13/hugo/commands.serve(0x521)
    /home/parallels/.gopathBuild/src/github.com/spf13/hugo/commands/server.go:69 +0x3fa
created by github.com/spf13/hugo/commands.NewWatcher
    /home/parallels/.gopathBuild/src/github.com/spf13/hugo/commands/hugo.go:194 +0x28f

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0x210ad7cd8)
    /usr/local/go/src/pkg/runtime/sema.goc:199 +0x30
sync.(*WaitGroup).Wait(0x210b92180)
    /usr/local/go/src/pkg/sync/waitgroup.go:127 +0x14b
github.com/spf13/hugo/commands.NewWatcher(0x521, 0x0, 0x0)
    /home/parallels/.gopathBuild/src/github.com/spf13/hugo/commands/hugo.go:197 +0x29f
github.com/spf13/hugo/commands.server(0x8bc520, 0x210aa4e40, 0x0, 0x3)
    /home/parallels/.gopathBuild/src/github.com/spf13/hugo/commands/server.go:53 +0x24a
github.com/spf13/cobra.(*Command).execute(0x8bc520, 0x210a35020, 0x3, 0x3, 0x0, ...)
    /home/parallels/.gopathBuild/src/github.com/spf13/cobra/command.go:273 +0x116
github.com/spf13/cobra.(*Command).findAndExecute(0x8bc440, 0x210a35010, 0x4, 0x4, 0x0, ...)
    /home/parallels/.gopathBuild/src/github.com/spf13/cobra/command.go:259 +0xa8
github.com/spf13/cobra.(*Command).Execute(0x8bc440, 0x0, 0x0)
    /home/parallels/.gopathBuild/src/github.com/spf13/cobra/command.go:308 +0x66e
github.com/spf13/hugo/commands.Execute()
    /home/parallels/.gopathBuild/src/github.com/spf13/hugo/commands/hugo.go:52 +0x2f
main.main()
    /home/parallels/.gopathBuild/src/github.com/spf13/hugo/main.go:21 +0x1a

goroutine 24 [chan receive]:
github.com/howeyc/fsnotify.(*Watcher).purgeEvents(0x210b508f0)
    /home/parallels/.gopathBuild/src/github.com/howeyc/fsnotify/fsnotify.go:21 +0x41
created by github.com/howeyc/fsnotify.NewWatcher
    /home/parallels/.gopathBuild/src/github.com/howeyc/fsnotify/fsnotify_bsd.go:103 +0x2fd

goroutine 23 [syscall]:
syscall.Syscall6(0x16b, 0x2f, 0x0, 0x0, 0x210b01000, ...)
    /usr/local/go/src/pkg/syscall/asm_darwin_amd64.s:41 +0x5
syscall.kevent(0x2f, 0x0, 0x0, 0x210b01000, 0xa, ...)
    /usr/local/go/src/pkg/syscall/zsyscall_darwin_amd64.go:199 +0x85
syscall.Kevent(0x2f, 0x0, 0x0, 0x0, 0x210b01000, ...)
    /usr/local/go/src/pkg/syscall/syscall_bsd.go:431 +0x9d
github.com/howeyc/fsnotify.(*Watcher).readEvents(0x210b508f0)
    /home/parallels/.gopathBuild/src/github.com/howeyc/fsnotify/fsnotify_bsd.go:328 +0x31b
created by github.com/howeyc/fsnotify.NewWatcher
    /home/parallels/.gopathBuild/src/github.com/howeyc/fsnotify/fsnotify_bsd.go:102 +0x2e6

goroutine 25 [select]:
github.com/spf13/hugo/commands.func·006()
    /home/parallels/.gopathBuild/src/github.com/spf13/hugo/commands/hugo.go:172 +0x23c
created by github.com/spf13/hugo/commands.NewWatcher
    /home/parallels/.gopathBuild/src/github.com/spf13/hugo/commands/hugo.go:185 +0x1de

goroutine 26 [finalizer wait]:
runtime.park(0xc600, 0x8c4268, 0x8c0d68)
    /usr/local/go/src/pkg/runtime/proc.c:1342 +0x66
runfinq()
    /usr/local/go/src/pkg/runtime/mgc0.c:2276 +0x84
runtime.goexit()
    /usr/local/go/src/pkg/runtime/proc.c:1394
@philips
Copy link
Contributor Author

philips commented Jan 12, 2014

Based on the FAQ comment here it seems nothing can be done: https://github.com/howeyc/fsnotify

Perhaps the best solution it to add a "watch mask"? I have lots of static files that will hardly ever change.

@xaprb
Copy link

xaprb commented Jan 15, 2014

I think a reasonable workaround is to set ulimit -n.

On Mac OSX in particular, -n has a ridiculously small default on my machine.

$ ulimit -n
256
$ ulimit -n 10240
$ ulimit -n
10240

Then it doesn't crash for me. However, I don't think it should panic, either. Panicking is really bad behavior for a program such as this. It should be printing an error and continuing to try to run, or if that's unrecoverable, exiting with a nonzero code, but not panicking.

@xaprb
Copy link

xaprb commented Jan 15, 2014

I disagree that nothing can be done. I haven't tried it, but I would be surprised if you couldn't make a sysctl to change ulimit, even if it needed to be done via cgo.

@xaprb
Copy link

xaprb commented Jan 15, 2014

Yeah, with a cursory search I think this is the right place to do it: http://golang.org/pkg/syscall/#Setrlimit

@spf13
Copy link
Contributor

spf13 commented Jan 15, 2014

Thanks for digging into this. Care to make a PR?

Steve Francia
spf13.com
@spf13

On Jan 14, 2014, at 7:53 PM, Baron Schwartz notifications@github.com wrote:

Yeah, with a cursory search I think this is the right place to do it: http://golang.org/pkg/syscall/#Setrlimit


Reply to this email directly or view it on GitHub.

@spf13 spf13 closed this as completed in 3e87d7a Feb 1, 2014
@philips
Copy link
Contributor Author

philips commented Feb 1, 2014

Thanks!
On Feb 1, 2014 9:51 AM, "Steve Francia" notifications@github.com wrote:

Closed #168 #168 via 3e87d7ahttps://github.com/spf13/hugo/commit/3e87d7a86e5dcd244dd713c8712a26f51f02be87
.

Reply to this email directly or view it on GitHubhttps://github.com//issues/168
.

@chibicode
Copy link

@spf13 @xaprb I'm still seeing this issue...

$ hugo version                                                                                                                                                                                           
Hugo Static Site Generator v0.14-DEV BuildDate: 2015-02-22T01:09:28-07:00
$ find . -type f | wc -l
10567
$ hugo server --theme=hugo-theme-shiori --watch 
...
Serving pages from /Users/shu/code/HugoBasicExample/public
Web Server is available at http://localhost:1313/
Press Ctrl+C to stop
ERROR: 2015/03/08 Error: listen tcp :1313: too many open files in system

By the way, my theme (--theme=hugo-theme-shiori) is using gulp to handle assets, and as a result, needs pull in a lot of node packages inside its node_modules directory. That's why there's a bloat.

One way to avoid this would be if --watch option had a way to ignore certain directories. Just for comparison, Jekyll has exclude option. I couldn't find anything comparable in Configuring Hugo page.

@bep
Copy link
Member

bep commented Mar 9, 2015

@chibicode Are you REALLY synching node_modules? Why? You don't need an ignore feature to fix your problem. Just use Gulp to build just what you need into /static.

@chibicode
Copy link

@bep the problem is that my node_modules currently lives under my theme directory (node_modules contains all of the gulp plugins I'm using)

image

And while I develop my theme, I use HugoBasicExample repo to test it, like this:

image

And when I try to run HugoBasicExample above with --watch flag, it'll die b/c of all the files inside node_modules.

Anyway, I'm pretty sure there's a workaround, but I can't find anything simple that meets the following requirements:

  1. Lets me use tons of gulp plugins (even though node_modules dir will be .gitignore'ed, each plugin needs to live in the theme's directory during development)
  2. Lets me develop the theme while having --watch on.

I'm not saying I'd like this feature implemented. I just wish it existed.

@anthonyfok
Copy link
Member

Hi @chibicode,

Just double checking:

  1. Are you running Hugo on Mac OS X?
  2. Does it work if you were to run ulimit -n 65536 before you run hugo with --watch on?

@anthonyfok
Copy link
Member

Hi @chibicode, more questions for you:

  1. If you are running OS X, which version?

  2. If 10.9 (Maverick) or 10.10 (Yosemite), could you please read this http://unix.stackexchange.com/questions/108174/how-to-persist-ulimit-settings-in-osx-mavericks and see if this is indeed what you observe, i.e. ulimit -n 16384 is the highest you can go?

  3. If so, could you please start another Terminal and try

    $ ulimit -n 999999
    $ ulimit -n
    

    and paste the output here?

  4. What does hugo check ulimit show on your system? (I just discovered this command, only available on OS X! See hugo/commands/limit_darwin.go.)

Many thanks!

P.S. Strangely, I cannot reproduce this problem on my Debian GNU/Linux at all, not even after I did this: ulimit -n 512 even when I have 16000+ files in my themes/hugo-theme-shiori/ directory. Does --watch work in different ways on different OSes?

P.P.S. Edited this post to change hugo ulimit to hugo check ulimit

@anthonyfok anthonyfok reopened this Mar 10, 2015
@anthonyfok
Copy link
Member

Looking through git log:

  1. 2014-02-01: @spf13 fixed this issue with commit 3e87d7a

    commit 3e87d7a86e5dcd244dd713c8712a26f51f02be87
    Author: spf13 <steve.francia@gmail.com>
    Date:   Sat Feb 1 12:51:11 2014 -0500
    
    Automatically increase the process ulimit to maximum available.  fixes #168.
    

    Tries to set the maxfile to 999999 whenever --watch is invoked.

  2. 2014-02-06: @spf13 limits this patch to OS X, because on Ubuntu Linux hugo server -w triggers "Error Setting rLimit operation not permitted", see hugo server -w triggers "Error Setting rLimit operation not permitted" #194.

    commit 75c260fa1ca4277cf1ef455cfd897bd315ab92a7
    Author: spf13 <steve.francia@gmail.com>
    Date:   Thu Feb 6 00:12:05 2014 -0500
    
    Only change rLimit on OSX (where it is needed). Fixed #194
    
    commit 11ca84f8cb19f01b7977b549e63e0ce0d126054e
    
  3. 2014-02-17: @mattn fixed the build on Windows (Build errors on windows #196, Fix build #199) See 8ebb85f

  4. There are some more refactoring, and hugo check ulimit and tweakLimit() now resides in commands/limit_darwin.go and commands/limit_others.go.

The code in commands/limit_darwin.go looks alright to me. Hmm...

@anthonyfok
Copy link
Member

Hi @chibicode,

The following appear to be one of the most comprehensive info on max open files limit on Mac OS X. Please take a look:

In particular, OS X Yosemite (10.10), which came out in October 2014, eight months after the aforementioned fixes, has made changes to how this limit is set.

You may also try this for a quick fix:

$ sudo sysctl -w kern.maxfiles=65536
$ sudo sysctl -w kern.maxfilesperproc=65536
$ ulimit -n 65536 65536    

Please let us know how it works! Thanks!

anthonyfok added a commit that referenced this issue Mar 10, 2015
A local `node_modules` directory can easily contain
tens of thousands of files, easily exhausting the tiny
default max open files limit especially on OS X Yosemite,
in spite of the fact that  Hugo already had code in place
since February 2014 to try to raise the maxfiles ulimit.

Also skip `.git` and `bower_components` directories.

The file watching situation will improve when
https://github.com/go-fsnotify/fsevents become ready,
but until then, we will be thrifty.  :-)

Thanks to @chibicode for the suggestion.

See #168 for continued discussions.
@anthonyfok
Copy link
Member

Hi @chibicode,

I am being adventurous and decided to take up your suggestion, and committed b9b70fb to skip node_modules/ as well as bower_components and .git/ directories. Even though Hugo tries to raise the relevant ulimit on OS X whenever --watch is used, having tens of thousands of files inside node_modules can easily exceed the default hard limit (?) of say 16384 files. So, I though I will go ahead and try it out. Afterall, it is still early in the v0.14 release cycle, and I am sure @bep will help me clean up the mess in case I goofed up. 😉

It turns out many of the mysteries can be explained by reading about fsnotify, the nifty library maintained by @nathany et al. that allows Hugo to watch for file changes using the same API across all platforms. Its FAQ at https://github.com/go-fsnotify/fsnotify/wiki/FAQ has the following important information:

How many files can be watched at once?

There are OS-specific limits as to how many watches can be created:

  • Linux: /proc/sys/fs/inotify/max_user_watches contains the limit, reaching this limit results in a "no space left on device" error.
  • BSD / OSX: sysctl variables "kern.maxfiles" and "kern.maxfilesperproc", reaching these limits results in a "too many open files" error.

Also, according to https://github.com/go-fsnotify/fsnotify/, fsnotify uses kqueue on OS X (and BSD too!), but inotify on Linux, which explains why lowering the ulimit maxfiles does not affect Linux at all! The planned use of FSEvents on OS X will do away with the silly maxfiles limitation and should hopefully make life easier for Hugo users on OS X.

Last but not least... should we keep the discussion here? Or should we start a new issue and continue from there? Afterall, this bug was already fixed in February/March 2014 last year. ;-)

Cheers,
Anthony

@chibicode
Copy link

Hi @anthonyfok, wow, thank you so much for such a thorough response. I did try ulimit -n but yes, I couldn't get it to go past 10240. I tried your commands but the last one returned limit: setrlimit failed: invalid argument.

$ hugo check ulimit
Current rLimit: {4864 9223372036854775807}
Attempting to increase limit
rLimit after change: {10240 10240}

$ sudo sysctl -w kern.maxfiles=65536
kern.maxfiles: 12288 -> 65536

$ sudo sysctl -w kern.maxfilesperproc=65536
kern.maxfiles: 65536 -> 65536

$ ulimit -n 65536 65536
limit: setrlimit failed: invalid argument

Also thanks for b9b70fb - although this looks like a huge hack and I now feel bad for requesting this.

Sorry I'm on a hurry, but really appreciated your response.

mohae pushed a commit to mohae/hugo that referenced this issue Mar 15, 2015
Fixes gohugoio#922

add finalize command and tests to change draft status of specified content to false and set date to Now()

undraft command

Allow hyphens in shortcode name

Fixes gohugoio#929

Keep trailing slash when baseUrl contains a sub path

Before this commit, .Site.BaseUrl ended up as:

http://mysite.com/ => http://mysite.com/
http://mysite.com/sub/ => http://mysite.com/sub

Now it becomes:

http://mysite.com/ => http://mysite.com/
http://mysite.com/sub/ => http://mysite.com/sub/

Fixed gohugoio#931

Improve error message on missing shortcode inner content

Fixes gohugoio#933

Allow the same shortcode to  be used with or without inline content

Fixes gohugoio#934

Update Readme.md with additional contribution guides

Added Gitter badge

Restructure top of Readme.md

Fixing image in readme

Using a smaller Header Image

Tidying the Readme a bit more

Update github-pages-blog.md

change `hugo serve` to `hugo server`

Add benchmark for the shortcode lexer

Apply gofmt -s

Avoid panic when pagination on 0 pages

Fixes gohugoio#948

Prevent 404.html from prettifying into 404/index.html

Restore @realchaseadams's commit 348e123
"Force `UglyUrls` option to force `404.html` file name"
which got lost after some refactoring (commit 8db3c0b).

Remove the equivalent "force `UglyUrls`" code for `sitemap.xml`
because the refactored code now calls `renderAndWriteXML()`
which uses `WriteDestFile()` which does not prettify a filename.

Fixes gohugoio#939

Fix errors reported by Go Vet

Fix some Go Lint errors

Apply some more Golint suggestions

helpers: apply some Golint rules

author: fix doc

hugolib: apply some Hugolint rules

page: make receiver name on Page methods consistent

Apply some Golint rules on Page, esp. making the method receiver names consistent:

(page *Page) ==> (p *Page)

menu: make receiver name on Page methods consistent

Apply some Golint rules on Menu, esp. making the method receiver names consistent.

hugolib: apply some more Golint rules

source: apply some Golint rules

livereload: apply some Golint rules

parser: apply some Golint rules

There is only one s.PageTarget() - so we cannot change it, even tempoararily. We have to find another solution to this.
...

Prevent 404.html from prettifying into 404/index.html

Restore @realchaseadams's commit 348e123
"Force `UglyUrls` option to force `404.html` file name"
which got lost after some refactoring (commit 8db3c0b).

Remove the equivalent "force `UglyUrls`" code for `sitemap.xml`
because the refactored code now calls `renderAndWriteXML()`
which uses `WriteDestFile()` which does not prettify a filename.

Fixes gohugoio#939 (reverted from commit c4c19ad)

Handle 404 thread safely

Replaces hack that temporarily changes a global flag.

Fixes gohugoio#955
Fixes gohugoio#939

Fix UglyUrls on Windows

Fixes gohugoio#958

Fix eq and ne tpl function issue

`eq` and `ne` template functions don't work as expected when those are
used with a raw number and a calculated value by add, sub etc. It's
caused by both numbers type differences. For example, `eq 5 (add 2 3)`
returns `false` because raw 5 is `int` while `add 2 3` returns 5 with
`int64`

This normalizes `int`, `uint` and `float` type values to `int64`,
`uint64` and `float64` before comparing them. Other type of value is
passed to comparing function without any changes.

Fix gohugoio#961

Add test cases for Ne and Eq type normalisation

See gohugoio#961

Add new min_version field to theme.toml template

Switch from fsnotify.v0 to fsnotify.v1 API (watcher)

Fixes gohugoio#357
See also gohugoio#761

Do not parse backup files with trailing '~' as templates

Fixes gohugoio#964

absurlreplacer: write replacements directly to the byte buffer

The extra step isn't needed and this makes the code simpler.

And slightly faster:

benchmark              old ns/op     new ns/op     delta
BenchmarkAbsUrl        19987         17498         -12.45%
BenchmarkXmlAbsUrl     10606         9503          -10.40%

benchmark              old allocs     new allocs     delta
BenchmarkAbsUrl        28             24             -14.29%
BenchmarkXmlAbsUrl     14             12             -14.29%

benchmark              old bytes     new bytes     delta
BenchmarkAbsUrl        3512          3297          -6.12%
BenchmarkXmlAbsUrl     2059          1963          -4.66%

parser: add some frontmatter test cases

Skip directories like node_modules from the watchlist

A local `node_modules` directory can easily contain
tens of thousands of files, easily exhausting the tiny
default max open files limit especially on OS X Yosemite,
in spite of the fact that  Hugo already had code in place
since February 2014 to try to raise the maxfiles ulimit.

Also skip `.git` and `bower_components` directories.

The file watching situation will improve when
https://github.com/go-fsnotify/fsevents become ready,
but until then, we will be thrifty.  :-)

Thanks to @chibicode for the suggestion.

See gohugoio#168 for continued discussions.

Add some basic tests for doArithmetic

We might have to take precision into account for floating point nubers ... at some point.

doArithmetic: add test for division by zero

Correct initialisms as suggested by golint

First step to use initialisms that golint suggests,
for example:

    Line 116: func GetHtmlRenderer should be GetHTMLRenderer

as see on http://goreportcard.com/report/spf13/hugo

Thanks to @bep for the idea!

Note that command-line flags (cobra and pflag)
as well as struct fields like .BaseUrl and .Url
that are used in Go HTML templates need more work
to maintain backward-compatibility, and thus
are NOT yet dealt with in this commit.

First step in fixing gohugoio#959.

Remove trailing space from site build statistics

Update press coverage: Fix URL; new tutorial in Chinese

[Docs] Update and expand http://gohugo.io/overview/usage/

The `hugo help` output as shown in http://gohugo.io/overview/usage/
was not yet updated for v0.13. Thanks to @alebaffa for the heads up!

Also:
 - Clarify that, after using `hugo server`, the bare `hugo` command
   need to be run before deployment.
 - Add a section on running `hugo` as production web server,
   and add links to two blog posts of two Hugo users sharing
   their experience.

Partially fixes: gohugoio#852 and gohugoio#937

Add deprecated logger

Add double checking in Deprecated

To prevent possible duplicate log statements.

source: add some test cases for File

Do not ERROR-log missing /data dir

Fixes gohugoio#930

Experimental AsciiDoc support with external helpers

See gohugoio#470

 * Based on existing support for reStructuredText files

 * Handles content files with extensions `.asciidoc` and `.ad`

 * Pipes content through `asciidoctor --safe -`.
   If `asciidoctor` is not installed, then `asciidoc --safe -`.

 * To make sure `asciidoctor` or `asciidoc` is found, after adding
   a piece of AsciiDoc content, run `hugo` with the `-v` flag
   and look for this message:

        INFO: 2015/01/23 Rendering with /usr/bin/asciidoctor ...

Caveats:

 * The final "Last updated" timestamp is currently not stripped.

 * When `hugo` is run with `-v`, you may see a lot of these messages

        INFO: 2015/01/23 Rendering with /usr/bin/asciidoctor ...

   if you have lots of `*.ad`, `*.adoc` or `*.asciidoc` files.

 * Some versions of `asciidoc` may have trouble with its safe mode.
   To test if you are affected, try this:

        $ echo "Hello" | asciidoc --safe -
        asciidoc: ERROR: unsafe: ifeval invalid
        asciidoc: FAILED: ifeval invalid safe document

   If so, I recommend that you install `asciidoctor` instead.

Feedback and patches welcome!

Ideally, we should be using https://github.com/VonC/asciidocgo,
@VonC's wonderful Go implementation of Asciidoctor.  However,
there is still a bit of work needed for asciidocgo to expose
its API so that Hugo can actually use it.

Until then, hope this "experimental AsciiDoc support through external
helpers" can serve as a stopgap solution for our community. :-)

2015-01-30: Updated for the replaceShortcodeTokens() syntax change
2015-02-21: Add `.adoc` extension as suggested by @Fale

Conflicts:
	helpers/content.go

Add Seq template func

Very similar to GNU's seq.

Fixes gohugoio#552

Conflicts:
	tpl/template.go

Added image support to the sitemap.xml template

Conflicts:
	tpl/template_embedded.go

Revert "Added image support to the sitemap.xml template"

This reverts commit 3c147bd.

Fixes gohugoio#972

removed duplicate word in readme

delete finalize files
@nathany
Copy link
Contributor

nathany commented Oct 16, 2015

Hugo Static Site Generator v0.15-DEV BuildDate: 2015-10-15T10:07:58-06:00

I'm seeing a number of errors like this on OS X:

[info] Error while watching new path public/tags/golang/: open public/tags/golang: too many open files

I'm not sure why it's watching the public directory.

@spf13
Copy link
Contributor

spf13 commented Oct 16, 2015

That's very strange. We haven't seen these kind of errors in a while. It shouldn't be watching public ever.

@bep
Copy link
Member

bep commented Oct 16, 2015

@nathany are you sure this isn't something else running on your computer? Because this one is way above my pay grade to understand ...

find $GOPATH -name "*.go" | xargs grep -i "while watching"
/Users/bep/go/src/github.com/spf13/hugo/hugolib/page_test.go:       t.Fatalf("Empty files should not trigger an error. Should be able to touch a file while watching without erroring out.")

@nathany
Copy link
Contributor

nathany commented Oct 16, 2015

You're probably right, as I also have reflex running in the same Terminal to watch sass files for sassc. I'll have to double check where the error came from.

UPDATE: Yah, that was Reflex. Sorry for the false alarm.

@spf13 spf13 closed this as completed Nov 7, 2015
@hypertexthero
Copy link

Am also getting Error: listen tcp 127.0.0.1:1313: socket: too many open files after running hugo server --watch despite attempting to increase ulimit (ulimit -n 999999). This is happening on a blog converted from Jekyll with 2300+ posts. When I delete the folder with lots of posts, it works.

It may be due to Apple's System Integrity Protection utility 'csrutil' ignoring any attempts to increase ulimits. This is on OS X Yosemite 10.10.5.

I don't want to disable csrutil, so I guess I'll have to have to wait for FSEvents to be implemented in Hugo's OS X version before I can use it, unless there is another way?

@anthonyfok
Copy link
Member

Could Hugo use this?

FSEvents for Go (OS X) - Clean room implementation
https://github.com/fsnotify/fsevents

@nathany
Copy link
Contributor

nathany commented May 16, 2016

@anthonyfok I don't see why not. Though perhaps fsnotify will use fsevents, or a new replacement for fsnotify.

@anthonyfok
Copy link
Member

@nathany:

Though perhaps fsnotify will use fsevents

That would be awesome! :-D

@hypertexthero
Copy link

Regarding my May 14 comment, I found this command (sudo launchctl limit maxfiles 1000000 1000000) that lets me increase the maximum number of open file descriptors for the current session, and then hugo server --watch works!

@nathany
Copy link
Contributor

nathany commented Jun 29, 2016

Thanks @hypertexthero. It's probably worth adding that command to the fsnotify Wiki https://github.com/fsnotify/fsnotify/wiki or even a blog post on https://fsnotify.org/ (which uses Hugo, btw:-).

tychoish pushed a commit to tychoish/hugo that referenced this issue Aug 13, 2017
A local `node_modules` directory can easily contain
tens of thousands of files, easily exhausting the tiny
default max open files limit especially on OS X Yosemite,
in spite of the fact that  Hugo already had code in place
since February 2014 to try to raise the maxfiles ulimit.

Also skip `.git` and `bower_components` directories.

The file watching situation will improve when
https://github.com/go-fsnotify/fsevents become ready,
but until then, we will be thrifty.  :-)

Thanks to @chibicode for the suggestion.

See gohugoio#168 for continued discussions.
@github-actions
Copy link

github-actions bot commented Apr 5, 2022

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants