e0qdk

Src: danbooru

Day 1 release, GOG version -- no patches. 100% completion. Been stuck on the final boss for weeks. Finally beat it. Finally. 132h30m29s by in game timer; 148h45m by Lutris (out of game) timer.

Src: pixiv - danbooru

Src: pixiv - danbooru

Src: pixiv - danbooru

Src: danbooru

Src: pixiv - danbooru

Src: pixiv - danbooru

Src: danbooru

Src: twitter - danbooru

The Stoosbahn, also known as the Schwyz–Stoos funicular or Standseilbahn Schwyz–Stoos, is a funicular railway in the Swiss canton of Schwyz. It connects the Hintere Schlattli in the municipalities of Muotatal, Morschach, and Schwyz with the village and mountain resort of Stoos, above Morschach. On a length of 1.7 kilometres (1.1 mi), it overcomes a height difference of 744 metres (2,441 ft).

The new line has a maximum gradient of 110% (47.7°-angle slope) and is the steepest funicular railway in Switzerland and Europe, superseding the Gelmerbahn. The Stoosbahn railway operator has claimed it to be the steepest funicular in the world and marketed it as such.

I had some free time this weekend and I've spent some of it trying to learn Go since mlmym seems to be unmaintained and I'd like to try to fix some issues in it. I ran into a stumbling block that took a while to solve and which I had trouble finding relevant search results for. I've got it solved now, but felt like writing this up in case it helps anyone else out.

When running most go commands I tried (e.g. go mod init example/hello or go run hello.go or even something as seemingly innocuous as go doc cmd/compile when a go.mod file exists) the command would hang for a rather long time. In most cases, that was about 20~30 seconds, but in one case -- trying to get it to output the docs about the compile tool -- it took 1 minute and 15 seconds! This was on a relatively fresh Linux Mint install on old, but fairly decent hardware using golang-1.23 (installed from apt).

After the long wait, it would print out go: RLock go.mod: no locks available -- and might or might not do anything else depending on the command. (I did get documentation out after the 1min+ wait, for example.)

Now, there's no good reason I could think of why printing out some documentation or running Hello World should take that long, so I tried looking at what was going on with strace --relative-timestamps go run hello.go > trace.txt 2>&1 and found this in the output file:

0.000045 flock(3, LOCK_SH)         = -1 ENOLCK (No locks available)
25.059805 clock_gettime(CLOCK_MONOTONIC, {tv_sec=3691, tv_nsec=443533733}) = 0

It was hanging on flock for 25 seconds (before calling clock_gettime).

The directory I was running in was from an NFS mount which was using NFSv3 unintentionally. File locking does not work on NFSv3 out of the box. In my case, changing the configuration to allow it to use NFSv4 was the fix I needed. After making the change a clean Hello World build takes ~5 seconds -- and a fraction of a second with cache.

After solving it, I've found out that there are some issues related to this open already (with a different error message -- cmd/go: "RLock …: Function not implemented") and a reply on an old StackOverflow about a similiar issue from one of the developers encouraging people to file a new issue if they can't find a workaround (like I did). For future reference, those links are:

• https://github.com/golang/go/issues/37461
• https://github.com/golang/go/issues/48572
• https://stackoverflow.com/questions/68725100/rlock-storage-8d8b-150e-github-com-my-username-app-go-mod-function-not-impleme/68728663#68728663