commercialhaskell / stack

The Haskell Tool Stack
http://haskellstack.org
BSD 3-Clause "New" or "Revised" License
3.98k stars 842 forks source link

stack build in WSL - openAnonymousTempFileFromDir: inappropriate type (Is a directory) #5010

Open freeman42x opened 5 years ago

freeman42x commented 5 years ago

Steps to reproduce

Expected

Project to build successfully.

Actual

stack build --verbose
2.1.3.1 x86_64 hpack-0.31.2
2019-08-19 14:39:27.610378: [debug] Checking for project config at: /home/neo/Projects/fairy-tale-artificial-general-intelligence-solutions/Sources/Razvan Flavius Panda/Haskell/artificial-general-intelligence/stack.yaml
2019-08-19 14:39:27.611197: [debug] Loading project config file stack.yaml
2019-08-19 14:39:27.612420: [error] openAnonymousTempFileFromDir: inappropriate type (Is a directory)

Stack version

$ stack --version
2.1.3.1 x86_64 hpack-0.31.2

Method of installation

Installed stack via Nix.

freeman42x commented 5 years ago

I can't reproduce the error anymore. Builds successfully now.

freeman42x commented 5 years ago

I got the same issue on another project when trying to debug using: https://github.com/phoityne/phoityne-vscode

Error log:

CWD: /home/neo/Projects/haskell-stack-fix
CMD: stack ghci --with-ghc=haskell-dap --test --no-load --no-build --main-is TARGET --ghci-options -fprint-evld-with-show
Writing implicit global project config file to: /home/neo/.stack/global-project/stack.yaml
Note: You can change the snapshot via the resolver field there.
Using latest snapshot resolver: lts-14.1
openAnonymousTempFileFromDir: inappropriate type (Is a directory)

------------------------------------
can not parse ghci version. ["getGHCiVersion" (line 5, column 1):
unexpected end of input
expecting "GHCi, version "] assumes 8.0.0.
------------------------------------
:set prompt "H>>= "
dbaynard commented 5 years ago

Well openAnonymousTempFileFromDir comes from unliftio. Looks like the issue could be that the filepath provided lacks a trailing slash. Or perhaps the directory is being passed where a file is expected.

It's odd that it's intermittent, though. I wonder whether it's a WSL bug.

pepeiborra commented 5 years ago

I get this issue when building inside a nix-shell on RHEL6, so not WSL specific.

pikajude commented 5 years ago

I can also repro this when trying to stack build ghcjs. strace shows me

openat(AT_FDCWD, "/home/jude/.stack", O_WRONLY|O_TMPFILE, 0600) = -1 EISDIR (Is a directory)

however if I create ~/.stack/config.yaml with contents {} it seems to pick up on the fact that ~/.stack is a directory, then it fails further along the line. Must be a WSL bug.

sgalal commented 4 years ago

The same problem for me. I am using Arch Linux in WSL. I installed the latest version of stack via pacman.

ju1m commented 4 years ago

Same problem on Debian jessie using stack from nixpkgs-19.09 (stack 2.1.3.1 x86_64 hpack-0.32.0). The problem fails further along the line (stack now downloads the index) when using deprecated paths: ~/.stack/stack.yaml instead of ~/.stack/config.yaml and ~/.stack/global instead of ~/.stack/global-project. stack tries openat() on the directories ~/.stack or ~/.stack/global:

openat(AT_FDCWD, "/home/me/.stack/global-project", O_WRONLY|O_DIRECTORY|0x400000) = -1 EISDIR (Is a directory)

I cannot reproduce the problem on another setup, using Debian buster and nixpkgs-19.09 (stack 2.1.3.1 x86_64 hpack-0.32.0). The problem goes away when downgrading to nixpkgs-19.03 (stack 1.9.3 x86_64 hpack-0.31.2).

buwailee commented 4 years ago

A possible solution: try wsl2

pikajude commented 4 years ago

Unfortunately WSL2 isn't a viable solution to anything, not until they fix the unbounded memory leak problem :/

ncihnegn commented 4 years ago

Same issue on Arch WSL 1

NickSeagull commented 4 years ago

Just adding my +1

ahri commented 4 years ago

Just a note; the ubuntu-packaged version works, so this worked for me:

$ sudo apt install haskell-stack && stack upgrade
NickSeagull commented 4 years ago

Yep, it works from the official installer, the issue is with the Nix one, so perhaps we should open this ticket in nixpkgs?

sgalal commented 4 years ago

Yep, it works from the official installer, the issue is with the Nix one, so perhaps we should open this ticket in nixpkgs?

No. As I commented before, it is not a Nix-only issue.

Neurognostic commented 4 years ago

Seeing the same issue in Arch on WSL 1. Not intermittent.

Is there any known workaround?

Neurognostic commented 4 years ago

Found a workaround.

tldr:

pacman -S stack
mkdir -p ~/.stack
echo {} > ~/.stack/config.yaml
/usr/sbin/stack upgrade --force-download
stack build

With the stack package downloaded from the Arch Community repository my projects fail to build:

$ pacman -S stack
$ /usr/sbin/stack --version
Version 2.1.3, Git revision b2e2f3d0568e6d73fc0477dee8ca7c04466ec1f6 (dirty) (7736 commits) x86_64
Compiled with:
- Cabal-2.4.0.1
- Glob-0.10.0
...
- zip-archive-0.4.1
- zlib-0.6.2.1

Warning: this is an unsupported build that may use different versions of
dependencies and GHC than the officially released binaries, and therefore may
not behave identically.  If you encounter problems, please try the latest
official build by running 'stack upgrade --force-download'.

When building with this version the error is shown. If I try to follow the above warning's guidance and to install an "official release" the error is shown again.

[error] openAnonymousTempFileFromDir: inappropriate type (Is a directory)

Following @pikajude's suggestion to create ~/.stack/config.yaml with only {} still gave me the error when building my projects, but it did allow me to install the "official" stack release.

mkdir -p ~/.stack
echo {} > ~/.stack/config.yaml

NOTE: config.yml does not work. The same error is shown. Must use .yaml extension.

# Install official build
stack upgrade --force-download

# Check new version / git revision
/usr/sbin/stack --version
Version 2.1.3, Git revision 636e3a759d51127df2b62f90772def126cdf6d1f (7735 commits) x86_64 hpack-0.31.2

Now my projects build successfully.

CC: @felixonmars ( Arch stack package maintainer)

Neurognostic commented 4 years ago

The AUR stack-bin package also works without needing to manually create ~/.stack/config.yaml.

git clone https://aur.archlinux.org/stack-bin.git
cd stack-bin
makepkg --syncdeps --clean
$ /usr/sbin/stack --version
Version 2.1.3, Git revision 0fa51b9925decd937e4a993ad90cb686f88fa282 (7739 commits) x86_64 hpack-0.31.2
hongy19 commented 4 years ago

I added a Archlinux bug on this issue https://bugs.archlinux.org/task/65263

eli-schwartz commented 4 years ago

Don't report bugs for your frankenstein Microsoft system. Arch Linux does not recognize WSL as valid Arch Linux and we don't provide support for it.

We are not your support channel for the fact that Microsoft's WSL emulation layer is incomplete and doesn't work 100%.

...

Especially since you claimed in your Arch Linux bug report that "but other distribution package and The AUR stack-bin package doesn't has this issue", when this github issue quite plainly demonstrates that other distribution packages do have the issue... on WSL... even if the upstream prebuilt binaries do not.

carlosdagos commented 4 years ago

Had the same issue using nix in Ubuntu-20.04 in WSL1, I did part of what @Neurognostic has above.

mkdir -p ~/.stack
echo {} > ~/.stack/config.yaml

The error went away for the initial stages (downloading the index), but came back whilst trying to actually build a project and I couldn't find a way around it.

My solution for now: I downloaded the statically linked binary from the releases page. That one seems to be doing the work smoothly.

For anybody else making the dubious but courageous effort to use WSL1 mixed with nix, so far what seems to be the smoothest:

By enabling nix in the stack config, you will just inherit a bunch of stuff required to configure packages (gcc, make, gmp), which don't come with Ubuntu 20.04 by default.

Having said that, it seems that WSL is full of fun times 😄

and-pete commented 4 years ago

Also received openAnonymousTempFileFromDir: inappropriate type (Is a directory) when installing ghc-8.8.3 via stack on Ubuntu 18.04 on WSL1.

What's different for me compared to many comments above is that I was not using nix at all. Just straight Ubuntu.

stack --version gives Version 2.4.0, Git revision 9dcef52902d01646d63fe76fc8e6b1b3ac6cc9b8 from using stack upgrade --git

edit: dropped down to stack Version 2.3.1 through the overwriting upgrade instruction curl -sSL https://get.haskellstack.org/ | sh -s - -f (from here: https://docs.haskellstack.org/en/stable/install_and_upgrade/#upgrade This fixed the problem.

dten commented 4 years ago

encountered this recently and tracked it to this change. reverting the changes to Prelude here make the error go away. https://github.com/commercialhaskell/stack/commit/62c24fa0552dc722260f1cee75325145e837ab6a#diff-748b3631a8e26a9b793853e343ca0577

dten commented 4 years ago

What i don't understand is why the binary from stack upgrade --binary-version 2.3.1 works fine but building the tag v2.3.1 (with stack install) creates a stack can't build anything because of the error in this issue i'm on Windows 2004 with WSL 1 runng Ubuntu 18.04 by the way

edit: guessing the release is built with stack-ghc-84.yaml which uses an older RIO which does not have this issue

aryairani commented 1 year ago

I tried this:

mkdir -p ~/.stack
echo {} > ~/.stack/config.yaml

and then my system BSOD/rebooted during stack build. I tried it twice and then stopped trying. Sorry I'm not leaving much system config here due to effort/laziness, but I wanted to mention it.