-
-
Notifications
You must be signed in to change notification settings - Fork 7.4k
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
[arm64] "hugo -s docs" fails with "function not implemented" #1772
Comments
After adding log.SetFlags(log.LstdFlags | log.Lshortfile) to Hugo’s main.go (credit: http://stackoverflow.com/questions/24809287/how-do-you-get-a-go-golang-program-to-print-the-line-number-of-the-error-it-ju), the source of the error became more apparent:
The error messages were printed by And, in the case of the current Debian Hugo package, which was compiled with an older viper (commit dated 20151224) and older fsnotify (1.2.1 vs the current 1.2.8), the error was printed a bit earlier, by
Nevertheless, they both happen inside viper.WatchConfig() (hence fsnotify), which is called from either commands/hugo.go or commands/server.go, depending on which Hugo command is run. I will look inside fsnotify next, as I suspect fsnotify could be using a syscall function that is not available on Linux/arm64 for one reason or another, like in golang/go#11918. Anyhow, this does bring up a question: |
See gohugoio#1772 Also, force DisableLiveReload to true when running "hugo --watch" (build-only non-server mode) to prevent livereload.ForceRefresh(), which would end up blocking watchConfig() forever, from being called because livereload.Initialize() is never called in this case. This fixes the bug where "hugo --watch" could only reload config.toml once before it gets stuck for good at livereload.ForceRefresh(). This is also consistent with Hugo's existing behaviour: Non-server "hugo --watch" has never injected livereload.js since the inception of the "watch" feature in Hugo v0.12.
It turns out the "function not implemented" (ENOSYS) errors originated from Line 85 in inotify_poller.go from fsnotify: n, errno := syscall.EpollWait(poller.epfd, events, -1) Why? Because epoll_wait is deprecated according to a slideshow by Linaro who ported Linux to ARM64, and therefore, only the newer epoll_pwait is provided on Linux/arm64. Problem is, Go has not yet implemented the corresponding EpollPwait, see the "Unimplemented" section of go/src/syscall/syscall_linux.go:948 and golang.org/x/sys/unix/syscall_linux.go:971. It seems that the Go developers are aware of the issue, see golang/go#10235, though the milestone there changed from Go1.5 to Go1.6Early, and now Unplanned... Oh well... We'll see what happens next. In the meantime, if anyone were really using Hugo on ARM64, we can happily report that all features work except |
See #1772 Also, force DisableLiveReload to true when running "hugo --watch" (build-only non-server mode) to prevent livereload.ForceRefresh(), which would end up blocking watchConfig() forever, from being called because livereload.Initialize() is never called in this case. This fixes the bug where "hugo --watch" could only reload config.toml once before it gets stuck for good at livereload.ForceRefresh(). This is also consistent with Hugo's existing behaviour: Non-server "hugo --watch" has never injected livereload.js since the inception of the "watch" feature in Hugo v0.12.
Looks like it has been fixed in golang.org/x/sys/unix, thanks to Riku Voipio (@suihkulokki) in commit golang/sys@324e137, and the upstream golang/go#10235 has closed accordingly. I would like to refresh relevant Go packages in Debian and make sure it is all working properly on arm64 test machine before coming back and close this issue. :-) |
Fixed by Riku Voipio in golang/sys@324e137 and fsnotify/fsnotify#135 (committed by Nathan Youngman). Thank you all! |
@anthonyfok we should add this to the release notes for 0.16 On Wed, Apr 20, 2016 at 2:53 PM Anthony Fok notifications@github.com
|
See gohugoio#1772 Also, force DisableLiveReload to true when running "hugo --watch" (build-only non-server mode) to prevent livereload.ForceRefresh(), which would end up blocking watchConfig() forever, from being called because livereload.Initialize() is never called in this case. This fixes the bug where "hugo --watch" could only reload config.toml once before it gets stuck for good at livereload.ForceRefresh(). This is also consistent with Hugo's existing behaviour: Non-server "hugo --watch" has never injected livereload.js since the inception of the "watch" feature in Hugo v0.12.
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. |
According to the Debian arm64 build daemon build log, a
hugo -s docs
would fail with "function not implemented" error:Initial code search on "function not implemented" led me to
golang.org/x/sys/unix
, Errno 38 or 0x26, i.e.,ENOSYS
.I was able to reproduce this on Debian arm64 developer machine asachi.debian.org, and it is not one single "function not implemented" errors, but random amount of it, from 9 errors to 94812 errors. I'll need more time to investigate.
Note that this problem does not affect
armhf
andarmel
platforms.The text was updated successfully, but these errors were encountered: