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

[arm64] "hugo -s docs" fails with "function not implemented" #1772

Closed
anthonyfok opened this issue Jan 13, 2016 · 6 comments
Closed

[arm64] "hugo -s docs" fails with "function not implemented" #1772

anthonyfok opened this issue Jan 13, 2016 · 6 comments

Comments

@anthonyfok
Copy link
Member

According to the Debian arm64 build daemon build log, a hugo -s docs would fail with "function not implemented" error:

# TODO: Add "hugo-docs" package in the future
obj-aarch64-linux-gnu/bin/hugo -s docs -d public/html --uglyURLs
2016/01/12 00:33:24 function not implemented
debian/rules:9: recipe for target 'override_dh_auto_build' failed

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 and armel platforms.

@anthonyfok anthonyfok changed the title On arm64, "hugo -s docs -d public/html --uglyURLs" fails with "function not implemented" On arm64, "hugo -s docs" fails with "function not implemented" Jan 13, 2016
@anthonyfok
Copy link
Member Author

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:

2016/01/13 04:17:32 viper.go:260: error: function not implemented
2016/01/13 04:17:32 viper.go:260: error: function not implemented
2016/01/13 04:17:32 viper.go:260: error: function not implemented
2016/01/13 04:17:33 viper.go:260: error: function not implemented
2016/01/13 04:17:33 viper.go:260: error: function not implemented
2016/01/13 04:17:33 viper.go:260: error: function not implemented
2016/01/13 04:17:33 viper.go:260: error: function not implemented
2016/01/13 04:17:33 viper.go:260: error: function not implemented
0 draft content
0 future content
165 pages created
0 non-page files copied
0 paginator pages created
41 tags created
0 groups created
in 1100 ms

The error messages were printed by log.Println("error:", err) on Line 260 inside a goroutine, hence the multiple and random numbers of errors. However, it does continue and finish rendering the site.

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 log.Fatal(error) on line 236, hence the one-shot error message and immediate exit:

2016/01/13 04:21:53 viper.go:236: function not implemented

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:
@spf13, should commands/hugo.go be running watchConfig() even when it is not running in watch mode?

anthonyfok added a commit to anthonyfok/hugo that referenced this issue Jan 13, 2016
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.
@anthonyfok
Copy link
Member Author

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 --watch. 😉

spf13 pushed a commit that referenced this issue Jan 29, 2016
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.
@anthonyfok
Copy link
Member Author

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

@anthonyfok
Copy link
Member Author

Fixed by Riku Voipio in golang/sys@324e137 and fsnotify/fsnotify#135 (committed by Nathan Youngman).
When compiled with the latest fsnotify v1.3.0, hugo serve (with --watch) works great on Linux/arm64 (aarch64). 👍

Thank you all!

@anthonyfok anthonyfok added this to the v0.16 milestone Apr 20, 2016
@spf13
Copy link
Contributor

spf13 commented Apr 22, 2016

@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
wrote:

Fixed by Riku Voipio in golang/sys@324e137
golang/sys@324e137 and fsnotify/fsnotify#135
fsnotify/fsnotify#135 (committed by Nathan
Youngman).
When compiled with the latest fsnotify v1.3.0, hugo serve (with --watch)
works great on Linux/arm64 (aarch64). [image: 👍]

Thank you all!


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1772 (comment)

@anthonyfok anthonyfok changed the title On arm64, "hugo -s docs" fails with "function not implemented" [arm64] "hugo -s docs" fails with "function not implemented" Jun 13, 2016
tychoish pushed a commit to tychoish/hugo that referenced this issue Aug 13, 2017
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.
@github-actions
Copy link

github-actions bot commented Apr 6, 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 6, 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

3 participants