gatsby: npm run develop results in address already in use 127.0.0.1:xxxx

This happens with the starter as well as customized apps.

Checking via netstat -a on Windows the ports in question all seem to be open and available, and although I am using the standard dev port 8000, I get the following error:

⠋  gatsby-source-wordpress  pull updates since last build
Error: listen EADDRINUSE: address already in use 127.0.0.1:63955
    at Server.setupListenHandle [as _listen2] (net.js:1318:16)
    at listenInCluster (net.js:1366:12)
    at GetAddrInfoReqWrap.doListen (net.js:1503:7)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:69:8)
Emitted 'error' event on Server instance at:
    at emitErrorNT (net.js:1345:8)
    at processTicksAndRejections (internal/process/task_queues.js:80:21) {  
  code: 'EADDRINUSE',
  errno: -4091,
  syscall: 'listen',
  address: '127.0.0.1',
  port: 63955
}

This happens with any other manually entered port as well. A fresh install may work for a bit but eventually fails as well. I have predominantly noticed this after changing Wordpress data and restarting the process, but can’t confirm that it only happens after changing data.

I am using a docker setup, but the problem persists when using Local by Flywheel

version: "3.8"

services:
  db:
    image: mariadb:10.5.8
    restart: always
    volumes:
      - db-data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
    ports:
      - 3306:3306

  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    ports:
      - "3000:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wordpress:/var/www/html

  adminer:
    image: adminer
    restart: always
    ports:
      - 8080:8080

volumes:
  db-data:
  wordpress:

Gatsby config:

  plugins: [
    {
      resolve: "gatsby-source-wordpress-experimental",
      options: {
        url: "http://localhost:3000/graphql",
      },
     // removed the other plugins for brevity
  ],

And versions (again edited for brevity):

"dependencies": {
    "gatsby": "^2.31.1",
    "gatsby-source-wordpress-experimental": "^7.0.3",
    "react": "^17.0.1",
    "react-dom": "^17.0.1",
  },

I don’t know where the process gets this port from 127.0.0.1:63955, since I either don’t specify it or stick to something shorter (e.g. -p 4000). I’ve also noticed that once the develop script is done and the dev url is shown, the process starts over as if it has trouble persisting the changes.

If I am forgetting anything please let me know and I will edit the post promptly. I have found similar posts but they always showed that the specified port was in use.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 28 (9 by maintainers)

Most upvoted comments

Hi there, it looks like several users are impacted by this bug, we’re prioritizing it and hope to have a fix in the next month. Completely unrelated, but in the meantime we’re working on a significant rewrite of CMS Preview 🎉

jackonawalk on May 25, 2021

I think I may have narrowed down what’s causing this. I believe it’s due to the WP plugin trying to source nodes before the dev server is ready 🤔 or at/near the moment that a code change is saved. I was able to reproduce by adding code to make it trigger node sourcing immediately when it started watching for changes. Can anyone who’s running into this issue try this canary release and let me know if it fixes the problem? gatsby-source-wordpress@5.7.0-alpha-wordpress.0+fe81b6e978

Thanks!

@TylerBarnes This worked for me!! Thank you so much. This was causing quite the headache!

kelleyco2 on May 31, 2021

btw you can get around this problem by setting process.env.WP_DISABLE_POLLING=1 as that var disables the part of the codebase that’s triggering this issue.

Confirming that setting process.env.WP_DISABLE_POLLING=1 is a valid work around.

gatsby info output:


System:
    OS: macOS 11.4
    CPU: (4) x64 Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.17.0 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.13 - /usr/local/bin/npm
  Languages:
    Python: 2.7.16 - /usr/local/bin/python
  Browsers:
    Chrome: 91.0.4472.77
    Safari: 14.1.1
  npmPackages:
    gatsby: ^3.6.0 => 3.6.0
    gatsby-plugin-force-trailing-slashes: ^1.0.4 => 1.0.5
    gatsby-plugin-gatsby-cloud: ^2.6.0 => 2.6.0
    gatsby-plugin-google-analytics: ^3.2.0 => 3.6.0
    gatsby-plugin-image: ^1.6.0 => 1.6.0
    gatsby-plugin-manifest: ^3.6.0 => 3.6.0
    gatsby-plugin-offline: ^4.6.0 => 4.6.0
    gatsby-plugin-react-helmet: ^4.6.0 => 4.6.0
    gatsby-plugin-root-import: ^2.0.6 => 2.0.6
    gatsby-plugin-sharp: ^3.6.0 => 3.6.0
    gatsby-plugin-sitemap: ^4.2.0 => 4.2.0
    gatsby-plugin-styled-components: ^4.6.0 => 4.6.0
    gatsby-plugin-typescript: ^3.6.0 => 3.6.0
    gatsby-source-filesystem: ^3.6.0 => 3.6.0
    gatsby-source-wordpress: ^5.5.0 => 5.6.0
    gatsby-transformer-sharp: ^3.6.0 => 3.6.0

esizer on May 31, 2021

I published another canary version that’s exactly the same as the one above but with the debugging console.log’s removed gatsby-source-wordpress@5.7.0-alpha-wordpress.8+e70deff92e.

TylerBarnes on Jun 1, 2021

@franciscocobas definitely not a silly question 😃 You can install it like yarn add gatsby-source-wordpress@5.7.0-alpha-wordpress.0+fe81b6e978 or npm install gatsby-source-wordpress@5.7.0-alpha-wordpress.0+fe81b6e978

TylerBarnes on Jun 1, 2021

@TylerBarnes This worked for me too. Thank you so much .

ali1059 on Jun 1, 2021

@crapsh00t , @franciscocobas , @ali1059 @AlexMorrisonDev716 (and anyone else) can you copy/paste the output of gatsby info here? I’m investigating this now but having a hard time reproducing it for some reason. It’d be helpful to try to spot any overlap between your setups.

System:
    OS: macOS 11.3
    CPU: (8) x64 Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.16.1 - /usr/local/bin/node
    npm: 6.14.12 - /usr/local/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 90.0.4430.212
    Safari: 14.1
  npmPackages:
    gatsby: ^3.5.0 => 3.5.0
    gatsby-cli: ^3.2.0 => 3.5.0
    gatsby-image: ^3.1.0 => 3.5.0
    gatsby-plugin-gatsby-cloud: ^2.5.0 => 2.5.0
    gatsby-plugin-google-analytics: ^3.5.0 => 3.5.0
    gatsby-plugin-google-tagmanager: ^3.5.0 => 3.5.0
    gatsby-plugin-image: ^1.3.0 => 1.5.0
    gatsby-plugin-react-helmet: ^4.3.0 => 4.5.0
    gatsby-plugin-sass: ^4.1.0 => 4.5.0
    gatsby-plugin-sharp: ^3.3.0 => 3.5.0
    gatsby-plugin-styled-components: ^4.1.0 => 4.5.0
    gatsby-source-filesystem: ^3.3.0 => 3.5.0
    gatsby-source-wordpress: ^5.5.0 => 5.5.0
    gatsby-transformer-sharp: ^3.3.0 => 3.5.0
  npmGlobalPackages:
    gatsby-cli: 3.1.0

franciscocobas on May 31, 2021

@TylerBarnes

System: OS: Linux 5.8 Ubuntu 20.04.2 LTS (Focal Fossa) CPU: (8) x64 Intel® Core™ i5-10210U CPU @ 1.60GHz Shell: 5.0.17 - /bin/bash Binaries: Node: 14.17.0 - /usr/bin/node Yarn: 1.22.5 - /usr/bin/yarn npm: 6.14.13 - /usr/bin/npm Browsers: Chrome: 91.0.4472.77 Firefox: 88.0.1 npmPackages: gatsby: ^3.1.2 => 3.6.1 gatsby-background-image: ^1.5.0 => 1.5.3 gatsby-plugin-emotion: ^6.1.0 => 6.6.0 gatsby-plugin-image: ^1.1.2 => 1.6.0 gatsby-plugin-preact: ^5.5.0 => 5.6.0 gatsby-plugin-react-helmet: ^4.1.0 => 4.6.0 gatsby-plugin-s3: ^0.3.8 => 0.3.8 gatsby-plugin-sharp: ^3.1.2 => 3.6.0 gatsby-source-filesystem: ^3.1.0 => 3.6.0 gatsby-source-graphql: ^3.1.0 => 3.6.0 gatsby-source-wordpress: ^5.6.0 => 5.6.0 gatsby-transformer-sharp: ^3.1.0 => 3.6.0 npmGlobalPackages: gatsby-cli: 3.6.0

ali1059 on May 31, 2021

btw you can get around this problem by setting process.env.WP_DISABLE_POLLING=1 as that var disables the part of the codebase that’s triggering this issue.

Awesome! 👏🏻

gabeboisvert on May 31, 2021

btw you can get around this problem by setting process.env.WP_DISABLE_POLLING=1 as that var disables the part of the codebase that’s triggering this issue.

TylerBarnes on May 31, 2021