Gatsby: [v2] gatsby build hangs on WSL Ubuntu

Created on 18 Jul 2018  Β·  16Comments  Β·  Source: gatsbyjs/gatsby

Description

Build hangs on "Building production Javascript and CSS bundles," after "bootstrap finished." This doesn't happen on Gatsby v1, or with gatsby develop.

Steps to reproduce

  1. Make a new gatsby site using command: gatsby new tutorial-part-one https://github.com/gatsbyjs/gatsby-starter-hello-world#v2.
  2. Run gatsby build.

Expected result

Gatsby should build the production site.

Actual result

Gatsby hangs on "Building production Javascript and CSS bundles." I let it run for 10 minutes and then quit. This occurs on both the gatsby-cli

Environment

  • System:

    • OS: Linux 4.4 Ubuntu 16.04.4 LTS (Xenial Xerus) (wsl on Windows build 17692)

    • CPU: x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz

    • Shell: 5.1.1 - /usr/bin/zsh

  • Binaries:

    • Node: 8.11.3 - /usr/local/bin/node

    • npm: 6.2.0 - /usr/local/bin/npm

  • npmPackages:

    • gatsby: next => 2.0.0-beta.46

    • gatsby-plugin-react-helmet: next => 3.0.0-beta.3

  • npmGlobalPackages:

    • gatsby-cli: 2.0.0-beta6

    • also occurs on -gatsby-cli: 1.1.58

File contents (if changed)

gatsby-config.js: N/A
package.json: N/A
gatsby-node.js: N/A
gatsby-browser.js: N/A
gatsby-ssr.js: N/A

question or discussion

Most helpful comment

Guys, looking for a workaround, I found out that the problem is caused during the uglify process when using wsl (there are some notes at webpack git talking about uglify hanging when parallel: true).

Setting parallel:false in node_modules/gatsby/dist/utils/webpack-utils.js -> plugins.minifyJs solved the issue for me.

Maybe it can be useful =]

All 16 comments

I couldn't recreate this just now on my mac. Perhaps this is a linux problem? Also npm occasionally just won't install things correctly so weird problems like this can be fixed by deleting node_modules and reinstalling. Can you try that?

I just had a try - didn't work. However I did manage to get gatsby build to work on the beta on a different Ubuntu machine. That machine is running Ubuntu 18.04 but otherwise has the same config.

Is there any way for me to pinpoint this issue better? The --verbose flag doesn't give me any new info.

Just wanted to chime in and say that the build script hanged on my machine as well, only it happened at the Building static HTML for pages step, after the Building production JavaScript and CSS bundles successfully finished. I am running KDE Neon (based on ubuntu 16.04), node v8.9.4, npm v.6.2.0. Something fishy is going on here...

Uh-oh, now it started working fine again. I swear it consistently hung after a fresh install of 2.0.0-beta.47. I removed node_modules and reinstalled dependencies several times, and it continued to freeze. And then, after one last reinstall, it started working again. Very strange.

~@pieh reported some oddities with WSL and a recent Windows update. Maybe this is the same thing?~

Edit: nevermind, looks like you're seeing this issue on other Linux machines too.

I've just checked the starter on my machine:

  System:
    OS: Linux 4.15 Ubuntu 18.04 LTS (Bionic Beaver)
    CPU: x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Shell: 4.4.19 - /bin/bash
  Binaries:
    Node: 8.11.3 - /usr/bin/node
    Yarn: 1.7.0 - /usr/bin/yarn
    npm: 5.6.0 - /usr/bin/npm
  Browsers:
    Chrome: 67.0.3396.99
    Firefox: 61.0.1
  npmPackages:
    gatsby: next => 2.0.0-beta.48 
gatsby build
success open and validate gatsby-config β€” 0.007 s
success load plugins β€” 0.081 s
success onPreInit β€” 0.021 s
success delete html and css files from previous builds β€” 0.007 s
success initialize cache β€” 0.004 s
success copy gatsby files β€” 0.007 s
success onPreBootstrap β€” 0.000 s
success source and transform nodes β€” 0.009 s
success building schema β€” 0.057 s
success createPages β€” 0.000 s
success createPagesStatefully β€” 0.013 s
success onPreExtractQueries β€” 0.000 s
success update schema β€” 0.037 s
success extract queries from components β€” 0.010 s
success run graphql queries β€” 0.008 s β€” 1/1 153.93 queries/second
success write out page data β€” 0.002 s
success write out redirect data β€” 0.000 s
success onPostBootstrap β€” 0.000 s

info bootstrap finished - 1.647 s

success Building production JavaScript and CSS bundles β€” 7.605 s
success Building static HTML for pages β€” 0.731 s β€” 1/1 11.18 pages/second
info Done building in 9.985 sec

Seams to work.

Right, got the issue (not sure whether it’s quite the same issue as reported in the original message) reliably reproduce on my machine:

Steps:

1) use gatsby v.2.0.0-beta.42
2) run gatsby build
3) build completes successfully

...

4) update gatsby to v.2.0.0-beta.47
5) run gatsby build (while keeping the public folder generated during the previous run)
6) build completes successfully

...

7) stay on gatsby v.2.0.0-beta.47
8) delete the public folder generated during the previous run
9) run gatsby build
10) build hangs at the stepBuilding static HTML for pages

===

Running ubuntu 16.04, node v8.9.4, npm v.6.2.0.

I am on (legacy) WSL and I run also in the following problem:
gatsby build (or yarn build) hangs on ⠐ Building production JavaScript and CSS bundles
gatsby@next and works on macos

node 10.1.0
npm 6.1.0
yarn 1.6.0

Building production JavaScript and CSS bundles never completed.

I am on Ubuntu WSL too

Distributor ID: Ubuntu
Description: Ubuntu 18.04 LTS
Release: 18.04
Codename: bionic

Gatsby version 2.0.0-beta.7
Yarn 1.7.0
Node v10.6.0

Anyone found a workaround for this yet? Or insight into which stage is causing the problem?

Updating to the latest windows insider build solved the issue for me.

πŸ‘ closing this. Please open a new issue if there's something we can do to help make using Gatsby smooth on WSL Ubuntu!

Guys, looking for a workaround, I found out that the problem is caused during the uglify process when using wsl (there are some notes at webpack git talking about uglify hanging when parallel: true).

Setting parallel:false in node_modules/gatsby/dist/utils/webpack-utils.js -> plugins.minifyJs solved the issue for me.

Maybe it can be useful =]

This issue has been fixed in #12636

Was this page helpful?
0 / 5 - 0 ratings