search

wasp-lang / wasp

The fastest way to develop full-stack web apps with React & Node.js.
https://wasp-lang.dev
MIT License
13.74k stars 1.18k forks source link

On sigkill (Ctrl+C) for `wasp` CLI, sometimes child processes remain running / occupying ports #198

Open Martinsos opened 3 years ago

Martinsos commented 3 years ago

It seems that in certain situations when Wasp crashes, nodejs server remains running on port 3000. The next time wasp is run, that causes a problem since port 3000 is already taken and it can't start a new nodejs server on that same port.

Ideal solution would be to never allow nodejs process to remain running once wasp process ends. I am not sure if we even ensure that though, due to Wasp CLI possibly not having the time to clean up if it is being killed immediately. Maybe there is a way to spawn nodejs process in such way that it dies automatically once Wasp process is dead? Is that supported by the Linux/OSX? Or maybe we can do this via Docker (I think they have an option to kill instance once parent process is dead or smth like that), but that means we switch to docker in development.

Another option might be to check for any left-over wasp processes once wasp is started again and clean them up first. This however means we have to be careful not to delete something that is not a Wasp process -> so we can't just delete the process that is occupying port 3000, we need to check that it is actually a wasp process. Also, this means the "runaway" process will be deleted only once you run wasp again -> if you don't, it might remain running and consuming resources, which is not cool.

One spin on that might be that we don't let Wasp kill that processes, instead we print useful error message telling user to kill them + exact commands do that.

So, while first suggestion is certainly the best, I am not sure if it is possible - we should investigate what can be done and what not and then pick an approach.

cursorial commented 3 years ago

Found a workaround for this while hacking on Thoughts on Ubuntu, simply run the following and then run Wasp again.

fuser -k 3000/tcp
fuser -k 3001/tcp
Martinsos commented 3 years ago

Thanks for sharing @cursorial , that should help!

So you encountered the problem? We introduced some changes that we hoped will make it so that processes are always cleaned up, but if you encountered it then this is now always true and we still have this problem.

Do you maybe know which error brought you into this situation? On which OS?

Martinsos commented 3 years ago

I can confirm this is unfortunately still happening. Very rarely, but I had it happen again after couple of month of not happening. I believe there is a rare case when certain factors come together and cause this.

Martinsos commented 3 years ago

I found a way to replicate it. When global authentication is not specified (meaning there is no auth field in app, specify auth field for any of the operations. Set it to true or false, doesn't matter. Run wasp start and you will get an error that auth can't be specified for specific operation if it is not enabled for the whole app. This is expected, and wasp start will crash, which is also expected. However, if you remove that auth and run wasp start again, you will get already running on port 3000 error -> this is not expected and is a problem.

Martinsos commented 3 years ago

Good way to go about this would be to check if something is running on port 3000 or 3001, and if so, ask user, interactively, if it is ok to kill those processes. Even better would be that we don't leave any processes running when wasp start crashes but we haven't managed to do that yet hm.

shayneczyzewski commented 2 years ago

While chasing down a different issue, I noticed this problem was likely caused by how we terminate the spawned Node jobs. It was addressed here: https://github.com/wasp-lang/wasp/pull/524 by terminating the entire process group, as the Node process spawned a child and grandchild process. No reoccurrences so far 🤞🏻 👍🏻

Martinsos commented 4 months ago

This seems to have happened again: https://discord.com/channels/686873244791210014/1250905353256960084/1250926580813791232 .

When I stop the wasp process developing locally(opensaas), using ctrl-c in iterm, the process keeps running in the background. Mac OS 13, iterm, wasp 0.13.2, it it killed the process, but released the console before it had maybe? but then previously I had several spun up that had been running in the background that I had to manually kill.