firebase / firebase-tools

The Firebase Command Line Tools
MIT License
4.02k stars 937 forks source link

Error: TIMEOUT: Port 8080 on localhost was not active within 30000ms #2379

Closed dave-k closed 2 years ago

dave-k commented 4 years ago

firebase-debug.log Cloud Firestore emulator quickstart I am getting the Timeout error running the emulators:exec command on an unchanged project.

I tried other ports 8081, 8082 and

$ sudo firebase emulators:exec --only firestore 'npm test'
$ firebase emulators:exec 'npm test'
$ firebase emulators:start

produced the same Timeout error.


./firebase/quickstart-nodejs/firestore-emulator/javascript-quickstart

macOS v 10.15.6

$ firebase --version
8.4.2
$ node --version
v14.4.0
$ 
$ firebase emulators:exec --only firestore 'npm test'
i  emulators: Starting emulators: firestore
i  firestore: Firestore Emulator logging to firestore-debug.log
i  emulators: Shutting down emulators.

Error: TIMEOUT: Port 8080 on localhost was not active within 30000ms
samtstern commented 4 years ago

@dave-k when you say "unchanged project" do you mean this was working before and has since stopped? I haven't seen an error like this on macOS yet, could you try two things:

  1. I don't think anyone on our team is using Node 14 yet, most of us are on 12 or below. Does changing your Node version change anything?
  2. If you change the host for the Firestore emulator to 0.0.0.0 instead of localhost does that change anything? You can set this in firebase.json alongside the port.
samtstern commented 4 years ago

Oh also I'm gonna transfer this issue over to the Firebase CLI repo.

dave-k commented 4 years ago

@samtstern Unchanged i.e. no changes made to the tests.

  1. node v10.21.0
  2. host: 0.0.0.0

Same Timeout error: [error] Error: TIMEOUT: Port 8080 on 0.0.0.0 was not active within 30000ms firebase-debug.log

firebase.json

{
  "firestore": {
    "rules": "firestore.rules"
  },
  "emulators": {
    "firestore": {
      "host": "0.0.0.0",
      "port": 8080
    }
  }
}

package.json

{
  "name": "cloud-firestore-emulator-javascript-quickstart",
  "version": "1.0.2",
  "description": "Cloud Firestore emulator testing",
  "scripts": {
    "format": "prettier --write **/*.js",
    "test": "mocha --timeout=10000"
  },
  "devDependencies": {
    "@firebase/testing": "^0.20.3",
    "mocha": "5.2.0",
    "prettier": "1.15.2"
  }
}
samtstern commented 4 years ago

@dave-k thanks for trying hose things ... I am still pretty stumped on this issue.

Could you try running the Firestore emulator JAR directly and see if it works for you:

java -jar ~/.cache/firebase/emulators/cloud-firestore-emulator-v1.11.4.jar

The exact version of the jar may vary but you should have a cloud-firestore-emulator-*.jar in that location. You can also pass --port=<number> if you don't want to use 8080.

dave-k commented 4 years ago

@samtstern

$ java -jar ~/.cache/firebase/emulators/cloud-firestore-emulator-v1.11.4.jar
API endpoint: http://localhost:8080
If you are using a library that supports the FIRESTORE_EMULATOR_HOST environment variable, run:

   export FIRESTORE_EMULATOR_HOST=localhost:8080

Dev App Server is now running.
samtstern commented 4 years ago

Thank you for all of your information and patience here. You've been super helpful so far.

So in the debug log I don't see Dev App Server is now running which means for some reason the java command we launch from inside the emulator suite is not running the same as the one you ran for me. Here's the last useful line:

[debug] [2020-06-20T02:42:41.242Z] Starting Firestore Emulator with command {"binary":"java","args":["-Duser.language=en","-jar","/Users/dkennedy/.cache/firebase/emulators/cloud-firestore-emulator-v1.11.4.jar","--host","0.0.0.0","--port",8080,"--rules","/Users/dkennedy/project-2/firebase/quickstart-nodejs/firestore-emulator/javascript-quickstart/firestore.rules"],"optionalArgs":["port","webchannel_port","host","rules","functions_emulator","seed_from_export"],"joinArgs":false} {"metadata":{"emulator":{"name":"firestore"},"message":"Starting Firestore Emulator with command {\"binary\":\"java\",\"args\":[\"-Duser.language=en\",\"-jar\",\"/Users/dkennedy/.cache/firebase/emulators/cloud-firestore-emulator-v1.11.4.jar\",\"--host\",\"0.0.0.0\",\"--port\",8080,\"--rules\",\"/Users/dkennedy/project-2/firebase/quickstart-nodejs/firestore-emulator/javascript-quickstart/firestore.rules\"],\"optionalArgs\":[\"port\",\"webchannel_port\",\"host\",\"rules\",\"functions_emulator\",\"seed_from_export\"],\"joinArgs\":false}"}}
[info] i  firestore: Firestore Emulator logging to firestore-debug.log {"metadata":{"emulator":{"name":"firestore"},"message":"Firestore Emulator logging to \u001b[1mfirestore-debug.log\u001b[22m"}}
[info] i  emulators: Shutting down emulators. {"metadata":{"emulator":{"name":"hub"},"message":"Shutting down emulators."}}

So the command it's trying to run is:

java -Duser.language=en \
  -jar /Users/dkennedy//.cache/firebase/emulators/cloud-firestore-emulator-v1.11.4.jar \
  --host "0.0.0.0" --port 8080 \
  --rules /Users/dkennedy/project-2/firebase/quickstart-nodejs/firestore-emulator/javascript-quickstart/firestore.rules

I guess the last thing to try here is running that exact command, maybe the rules file is somehow changing the result? Again I apologize for basically blind debugging this, I just can't reproduce this myself.

dave-k commented 4 years ago
$ java -Duser.language=en \
>   -jar /Users/dkennedy//.cache/firebase/emulators/cloud-firestore-emulator-v1.11.4.jar \
>   --host "0.0.0.0" --port 8091 \
>   --rules /Users/dkennedy/project-2/firebase/quickstart-nodejs/firestore-emulator/javascript-quickstart/firestore.rules
API endpoint: http://0.0.0.0:8091
If you are using a library that supports the FIRESTORE_EMULATOR_HOST environment variable, run:

   export FIRESTORE_EMULATOR_HOST=0.0.0.0:8091

Dev App Server is now running.
dinvlad commented 4 years ago

We have the same issue with cloud-firestore-emulator-v1.11.2.jar. What's weirder, it works on one developer's laptop and not another. Same code, same versions of everything (including Java).

Ross-Rawlins commented 4 years ago

any news on this? I am getting this issue as well when importing a large data set on start up

samtstern commented 4 years ago

@Ross-Rawlins that sounds like a different issue since nobody above has mentioned import! For the issue above we have not been able to reproduce it ourselves, and we really can't fix an issue we can't reproduce (although we acknowledge that it's a real issue)

beezital commented 4 years ago

Same issue on my side running MacOS too. It seems to be related to a networking condition involving java. I have timed java -jar ~/.cache/firebase/emulators/cloud-firestore-emulator-v1.11.5.jar to be 31 seconds before it succeeds starting. Obviously this is too long when firebase emulators:start times out after 30 seconds. I have a multi-WAN router establishing multiple network connections on different WANs (works great for standard browsing where fetching can happen in parallel). I have experienced other issues with this setup and involving java. Workaround So I tunneled my Mac's Internet access through a VPN and now java -jar ~/.cache/firebase/emulators/cloud-firestore-emulator-v1.11.5.jar starts instantaneously. And so does firebase emulators:start.

handersonc commented 4 years ago

Same issue here when I run firebase emulators:start --only firestore --import=./backupfolder

i emulators: Starting emulators: firestore i firestore: Detected non-emulator Firestore export at backupfolder i firestore: Importing data from backupfolder/mybackup.overall_export_metadata i firestore: Firestore Emulator logging to firestore-debug.log i emulators: Shutting down emulators. i firestore: Stopping Firestore Emulator i hub: Stopping emulator hub

Error: TIMEOUT: Port 8080 on localhost was not active within 30000ms

dracomithril commented 4 years ago

So I was fighting with that thing for some time checking every possibility and the I did

npm install -g firebase-tools

and surprise surprise it started working 🤷 why bits me but maybe it will help someone

ScottPierce commented 4 years ago

I'm having this same problem in Docker Ubuntu environments trying to run CI tests. This morning, it just kept failing left and right for some reason:

yarn run v1.22.5
$ cd firebase && firebase emulators:exec --only firestore "cd .. && yarn test"
âš   emulators: You are not currently authenticated so some features may not work correctly. Please run firebase login to authenticate the CLI.
i  emulators: Starting emulators: firestore
i  firestore: Firestore Emulator logging to firestore-debug.log
i  emulators: Shutting down emulators.
i  firestore: Stopping Firestore Emulator
i  hub: Stopping emulator hub

Error: TIMEOUT: Port 8080 on 0.0.0.0 was not active within 30000ms
dracomithril commented 4 years ago

Did you add FIREBASE_TOKEN as env variable as it's mentioned in documentation ?

ScottPierce commented 4 years ago

@dracomithril I don't think that's necessary to run tests. My current theory is that the computer that was running the build was constrained on resources, creating a slow startup time. We started seeing tests time out also. I reduced the number of parallel builds running on the server at one time, and haven't seen it since.

dracomithril commented 4 years ago

one probably odd question why

cd firebase && firebase emulators:exec --only firestore "cd .. && yarn test"

and not

"scripts": {
    ...
    "test": "firebase emulators:exec --only firestore jest"
  },

and regarding FIREBASE_TOKEN You are not currently authenticated so some features may not work correctly. Please run firebase login to authenticate the CLI. in my case it helped 🤷

ScottPierce commented 4 years ago

one probably odd question why

Because yarn test is the following script:

nx run-many --all --target=test --parallel --maxParallel 3

The above command is fairly complicated, and instead of duplicating it in multiple places, I'd rather centralize it into one place.

You are not currently authenticated so some features may not work correctly. Please run firebase login to authenticate the CLI. in my case it helped 🤷

This is unlikely to be the solution. It's likely the issue is still there, and it's just intermittent. I still haven't set that, and yet everything is working for me again because I simply stopped running 2 build tasks at the same time on the machine, and limited it to one. That ensures the emulator starts up faster.

brennengarland commented 4 years ago

I've been having this same problem the last few days out of the blue. I'm running firebase emulators:start --import=data and the output is:

i  emulators: Starting emulators: auth, functions, firestore, database, hosting
!  functions: The following emulators are not running, calls to these services from the Functions emulator will affect production: pubsub
!  Your requested "node" version "10" doesn't match your global version "12"
i  firestore: Importing data from C:\repos\proctr\data\firestore_export\firestore_export.overall_export_metadata
i  firestore: Firestore Emulator logging to firestore-debug.log
i  emulators: Shutting down emulators.
i  functions: Stopping Functions Emulator
i  firestore: Stopping Firestore Emulator
!  Firestore Emulator has exited upon receiving signal: SIGINT
i  hub: Stopping emulator hub

Error: TIMEOUT: Port 8080 on localhost was not active within 30000ms

This problem persists if I change the ports.

dracomithril commented 4 years ago

@brennengarland did you changed node version?

! Your requested "node" version "10" doesn't match your global version "12"

If yes maybe try to reinstall all packages 🤔

ScottPierce commented 4 years ago

@brennengarland If you are running it on CI, then you might not have a fast enough CI container. Otherwise, I'd be looking at how large your data import is. If the import happens before the emulator is live, that could be why it's taking longer than 30 seconds.

brennengarland commented 4 years ago

@ScottPierce it looks independent of the data because when I run firebase emulators:start --only firestore I have the same issue. The issue from looking at wireshark, seems to be that port 8080 is setting a reset and ack flag on it's response, causing firebase to keep sending packets to try to open the port

sam-gc commented 3 years ago

Hi folks, this definitely sounds like a bug (tracked internally at b/172852315).

nolafs commented 3 years ago

firebase emulators:start --only firestore works for me fine but when try to import the database, I'm getting the Timeout error. The database is large, my guess is that import is taking to long.

evilandfox commented 3 years ago

I had the same problem, but it resolved after adding rules_version = '2'; line on the beginning of firestore.rules file

kevin-mao commented 3 years ago

Having same issue as @nolafs - works fine without importing but shows this Timeout error when importing my database (import folder is 460.3 MiB and database contains around 22k documents). Is there any way to extend timeout?

gorishabh commented 3 years ago

After trying all the methods/steps mentioned above none of them worked for me BUT I found the solution on my machine so leaving it here as a reference.

The issue is caused by the multiple Network Adapters created by Oracle VirtualBox VM, I found that:

  1. Uninstalling the Oracle VirtualBox VM removes these Virtual Host adapters and solves the Timeout Error issue
  2. Disabling these Virtual Host adapters also solves the Timeout Error issue

I don't know exactly the reason why Disabling/Removing these Virtual Host adapters are solving the issue and the only possible argument that I can make is that Firebase Emulator has a limit of 30000ms after which it gets Timeout but running the jar file directly as stated by @samtstern opens the Dev server but takes a lot of time, This time is due to the presence of those Virtual Host adapters because disabling them individually one by one was indeed increasing the time and finally there is a threshold point when 30000ms is not the sufficient time window to (say)SCAN all of them!

erikologic commented 3 years ago

In my case, I have to start it with the laptop (MacOS Big Sur 11.3) in airplane mode. In this way, it possibly fails - but then finally work on the next launch, also with the wifi back on.

I noticed that if I manually launch the jar before doing the above trick, it will take ages to launch the firestore server. Disabling the wifi takes the startup to few secs.

I don't have any Virtual Adapter but am using the Cisco Umbrella Roaming Client - a DNS enterprise client that gives more than few headaches on my machine

erikologic commented 3 years ago

I think I found the solution: Firestore takes more than 30 secs to start. The timeout value is hardcoded so as users we can't do anything really.

I opened #3482 to:

erikologic commented 3 years ago

Closing #3482 and opening #3483 just for hardcoding the timeout to 60 secs.

Yoyoyoyoyoyoyo commented 3 years ago

Now I'm getting timeouts at 60 seconds instead of 30.

Update - calling the jar directly ended up working. All other methods timed out.

jdrin commented 3 years ago

Experiencing the same issue - timeouts with 60000ms, calling jar directly works and all other methods time out.

evelant commented 3 years ago

This started happening to me as soon as I upgraded from v9.20.0 to v9.21.0.

edit: rolling back versions didn't change anything. This just randomly started happening and now I can't run firestore emulator at all. Even running the java command directly and waiting longer does not work. Also re-downloaded firebase-tools and the emulator packages.

jdrin commented 3 years ago

@AndrewMorsillo Try running the command with admin privileges.

sudo firebase emulators:start --only firestore

evelant commented 3 years ago

@jdrin running as root makes no difference. Still times out and fails to start. firestore-debug.log contains no useful information:

Oct 26, 2021 7:44:13 AM com.google.cloud.datastore.emulator.firestore.websocket.WebSocketServer start
INFO: Started WebSocket server on ws://localhost:59597
API endpoint: http://localhost:8080
If you are using a library that supports the FIRESTORE_EMULATOR_HOST environment variable, run:

   export FIRESTORE_EMULATOR_HOST=localhost:8080

Dev App Server is now running.
sudo firebase emulators:start
i  emulators: Starting emulators: auth, functions, firestore, hosting, pubsub, storage
âš   functions: The following emulators are not running, calls to these services from the Functions emulator will affect production: database
✔  functions: Using node@17 from host.
i  firestore: Firestore Emulator logging to firestore-debug.log
i  emulators: Shutting down emulators.
i  functions: Stopping Functions Emulator
i  firestore: Stopping Firestore Emulator
i  hub: Stopping emulator hub

Error: TIMEOUT: Port 8080 on localhost was not active within 60000ms
evelant commented 3 years ago

I got the emulators running again by specifying host as "127.0.0.1" instead of the default "localhost". I have no idea what changed that caused it to stop working on localhost. All I did was modify firebase.json like so to add host

 "emulators": {
        "auth": {
            "port": 9099,
            "host": "127.0.0.1"
        },
        "functions": {
            "port": 5001,
            "host": "127.0.0.1"
        },
        "firestore": {
            "port": 8080,
            "host": "127.0.0.1"
        },
        "hosting": {
            "port": 5001
        },
        "ui": {
            "enabled": true
        },
        "pubsub": {
            "port": 8085,
            "host": "127.0.0.1"
        },
        "storage": {
            "port": 9199,
            "host": "127.0.0.1"
        }
    }
TrueMatthewKirkham commented 3 years ago

@AndrewMorsillo solution worked for me too. added the emulators with host as he did and it all worked.

bjornconstructors commented 3 years ago

Can confirm that @AndrewMorsillo's workaround works. Since downgrading does not work, this might have to do with a OS X related upgrade (?).

irving-luna commented 3 years ago

I had the same issue. For me, downgrading from node 17 to node 14 fixed it.

bjornconstructors commented 3 years ago

As extra information that might help contributors (via @irving-luna input): I noticed that Homebrew updated node recently. Very very likely this issue indeed only occurs on node 17. Would be great if someone can confirm.

torstenek commented 3 years ago

Confirm. Reverting to @16 solved the issue for me.

nick-w-nick commented 3 years ago

Can confirm that adding the host per @AndrewMorsillo's suggested solution worked for me while using Node v17.0.1.

huydinhle commented 3 years ago

Both downgrading and adding the host don't work for me but I'm trying to import large data set ( about 40gb). So there is no workarond for importing large data set?

bjornconstructors commented 3 years ago

For people running firebase emulators:start with the --import flag on large data sets like @huydinhle and @nolafs: my suggestion would be to not use --import but store whatever data store you have in a JSON file and import that after the emulators are running using a custom made population script. Your development flow would then to simply run this population script (each time) after starting the emulator. That way the importing process can take as long as you want and you could even add a nice progress bar as a bonus ;). Note that you likely also need a small script to dump the firestore data to that JSON file in the first place. Only other workaround there is to fork firebase-tools and adapt the timeout in the source code here https://github.com/firebase/firebase-tools/blob/0be4074d717c0e58f36ffe5b0cdc09cffe869f1f/src/emulator/portUtils.ts#L142

huydinhle commented 3 years ago

@bjornconstructors : Have 2 follow up questions for you about this

  1. How can you export your whole Firestore dataset into JSON ? Currently, I just use the export functionality from gcloud cli to get a backup from Firestore. How do I convert that 44 GB of data into JSON file? Is this going to be multiple JSON files?
  2. Can you give us some pointer in terms of how to create this population script? You mentioned about progress bar even so You have some thing in mind in how to make this work?
benedelstein commented 3 years ago

Specifying a host in firebase.json seemed to work for me, but then my firestore-triggered cloud functions were not firing, with the error WARNING: Failed to publish event to localhost:5001: Connection refused

I downgraded to node 16, removed the host key, and now it works.

TPXP commented 3 years ago

Hello there, I'm having a similar issue on MacOS Monterey with Node v17. Adding the host key to the configuration file fixed the startup, and gave me a possibility for the root cause of the issue. Indeed, I had the following line at the end of the my tests (to generate a firestore rules coverage report)

http.get(`http://localhost:${port}/emulator/v1/projects/${projectId}:ruleCoverage.html`, res => {
 // ...
})

This seems to crash as well ! Here's what I got

Error: connect ECONNREFUSED ::1:8090
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1161:16)
Emitted 'error' event on ClientRequest instance at:
    at Socket.socketErrorListener (node:_http_client:447:9)
    at Socket.emit (node:events:390:28)
    at emitErrorNT (node:internal/streams/destroy:164:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -61,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '::1',
  port: 8090
}

Replacing localhost by 127.0.0.1 fixed it, but I think localhost now resolves to ::1(IPv6) instead of 127.0.0.1 (IPv4). Maybe that's why the CLI thinks the emulator is not yet ready

Potentially linked to https://github.com/firebase/firebase-tools-ui/issues/332

stansotn commented 3 years ago

I tried numerous things mentioned above suffering from the issue described by OP. The only working solution for me was to downgrade to node 16 (from 17). I'm on Monterey 12.0.1 x86; firebase-tools 9.22.0 .

brew install node@16

# Relink node 17 executable to node 16
ln -sf /usr/local/Cellar/node@16/16.13.0/bin/node /usr/local/bin/node
evkalinin commented 3 years ago

As @stansotn mentioned, downgrade to 16 node work for me too. Catalina (10.15.7), tools - 9.22.0

brew unlink node
brew install node@16
brew link --overwrite node@16
jangruenwaldt commented 2 years ago

As @stansotn mentioned, downgrade to 16 node work for me too. Catalina (10.15.7), tools - 9.22.0

brew unlink node
brew install node@16
brew link --overwrite node@16

Can confirm, working on monterey. Thanks for the commands.