OpenSaas setup 'Role postgres does not exist'
Hi! I'm a bit stuck on the initial steps for openSaaS. Running on a fresh Ubuntu 22.04 VPS and following the Getting Started Docs. When doing 'wasp db migrate-dev' it takes forever(~40min now), I switched to the other terminal running the DB and can see error messages with 'Role postgres does not exist ' and 'password authentication failed for user "Postgres"'. I have done zero modifications, just following along the guide and not sure how to proceed here, new to Wasp and not sure what to adjust. Any tips appreciated - thanks!
36 Replies
Edit: i added the DB log
An update, I did a reboot and restart everything. Now after a few minutes getting a new error, saying
npm install failed: project setup failed with exit code -9
I guess will try to install npm manually?
Wohooo @wacko, you just became a Waspeteer level 1!
Seems npm is already installed, so very confused at this point..
Retried, now getting this
hmm have you checked the Node version?
won't be online now anymore, sorry, but can check more tmrw
Yes it's v18.19.1 .Had installed v14 previously, noticed it needs higher version so installed v18. Used snap to install/update it.
No worries!
Just a final update for today , I wiped the Snap installs of Node and reinstalled it from scratch, also cloned the template in a new directory and followed the Getting Started page again. Still got this:
Is it possible to view more detailed logs or enable debug mode? The
install failed, code -9 is not very helpful. 😕
Btw sorry if I'm spamming too much here, I thought it might be helpful to give as many details as possible, because if this case is fixed it will improve the getting started experience for others as well.@wacko Don't feel like you are spaming when giving use extra info to use to debug! Good job on reporting everything.
Okay, let's try the following list of steps to get more info:
1. Run
wasp clean to remove all the build artefacts
2. Run wasp db migrate-dev and see if that helps
If that doesn't work, let's try running the following:
1. wasp clean
2. wasp compile (internal command which won't start the project)
3. Go into the folder .wasp/out/web-app and run npm install there
4. Go into the folder .wasp/out/server and run npm install there
We are simulating a bit what Wasp is doing usually on its own just to see if we see some more error messages 😄Hi @miho !
Thanks for the tips. I just tried
wasp clean and wasp db migrate-dev and it got stuck on this message repeating for 15min '[ Wasp ] You've been waiting so patiently, just wait a little longer (for the installation to finish)...'
I stopped it, then tried wasp clean again and wasp compile. It was running for 10min, then gave this error message:
Btw meanwhile on my local PC I set up WSL with same ubuntu version as VPS and went the
wasp new -> saas route. And that works perfectly.
Just tried the wasp new -> saas method on the VPS box and getting the same npm install code -9 error.. So the issue must be something specific to my VPS or software config and not the saas template. Tomorrow will try to nuke the VPS and set up a new one and try it there. If there is a way to get more detailed logs than install failed please let me know.A way to get more detailed logs is to do what I mentioned above, run
wasp compile for a few minutes, then kill it, then run npm install manually in the .wasp/out/web-app and .wasp/out/server folders 😄 let's see what you get@miho I tried that and this is what I got:
Wohooo @wacko, you just became a Waspeteer level 2!
That last command it just gets stuck. First one it gives the
killed message very quickly.
But I think I figured out what could be the issue, the VPS is running with 512mb ram 😅
Have no time today, but tomorrow will try to resize the VPS and see if that helps. Then if that helps we can add a note in the getting started docs that it needs certain amount of memory. 😀@Vinny (@Wasp) we had a similar issue with low memory on Replit or some similar platform, no? 😄
yeah it was actually storage space of 1gb is not enough
so you could be hitting your limit if that's the case
make sure you have >1gb storage on the virtual machine
I have ~5GB free on it, so should be okay. I have a good feeling about the ram , will check and report back later. Cheers
Thanks for all the details @wacko , and I am sorry you had to go through this, but we will do our best to help others avoid it in the future, as you said.
@martinsos @miho @matijash So a final update I guess, I resized the VPS from 512 -> 1GB RAM and everything works flawlessly.
So it seems that was the main issue.
Also I had to do
sudo apt-get install xdg-utils since that was missing and throwing an error upon wasp start but that could be just my VPC issue.
Thanks for the help, I guess we can close this oneThat is because Wasp is trying to open a tab in your browser, and it needs xdg-utils for that (well Vite really does I guess, Wasp just uses Vite). -> so it isn't really a breaking thing, at least shouldn't be, but I guess it was in you rcase. I am a bit surprsied you didn't have it installed though, I thought Ubuntu comes with it normally.
Awesome, glad to know it is fixed!
@Wasp Team FYI this
npm install failed: Setup failed! Web app setup failed with exit code -9. issue started to appear over the last 5 days on our side as well and blocked the ci/cd pipeline entirely. We've got 2GB RAM, unlim hard drive and it still occurs
Any hints what -9 exit code means?
Here's what it looks like. Then the pod gets killed with OOMKilled error messageDid something change in the setup in the last 5 days?
Not at all, that's the problem 🙂 And the same commit that I've built successfully from 6 days ago is now failing
Are you still using Wasp 0.11.8?
0.11.5 to be more precise 😄
Later versions would have any optimizations?
This is literally the last issue that's stopping us from prod release
Latest have breaking changes like using package.json for deps management. And many more optimizations, but I'm not sure they directly touch the npm install issue you seem to be facing. It would be useful to jump on a call to investigate this together 🙂
If you can share with us if you use any npm deps in the Wasp file (here or DMs) that might help us.
Thought: it will take some effort to migrate to Wasp 0.13, but if you haven't deployed to production yet, maybe it is better to do it now then later, so you don't have to migrate production database if you decide to switch later!
@miho @martinsos is there a
verbose or debug flag for wasp build so that I can see more details on what's going on?
@Wasp Team FYI resizing the VPS from 512 -> 1GB RAM as @wacko did was not enough. I've had to go from 2GB to 4GB for build to work
The good news -- the issue is gone.
The bad news -- build from the same commit that succeeded a week ago with 2GB ram using the same wasp CLI version now requires twice as many RAM for some reason
I can see a pattern here when Wasp requires more RAM over time to build successfully, maybe it's worth to look into that or at least make the issue more descriptive than code -9 😄Hm @maksym36ua , so you said this is happening during
npm install, right? But I see it peaks to 4GB, then falls back to 2GB. So it is decompressing some stuff while installing?
Ok, so you said it happens although you made no code changes. This is probably because Wasp doesn't yet have proper "npm lock" / "dependency freeze" story in place, and what is possible is that one of the dependencies in the tree changed its patch version and so the new version got pulled in and it caused these issues.
Once we have a better "dep freeze" story, this shouldn't be happening any more -> we will be taking care of that for Wasp 1.0 for sure.
Also, we will make sure to do some optimizing of speed and memory for Wasp -> as you said, we don't want it changing without us knowing.
That said, what we can possibly do now is take a look at what is cause in this case, that might help both of us in the long run.
Some ideas;
1. So the command that causes trouble in the CI, run that same command locally, and let's see if it also consumes that much RAM. If it does, great, we can replicate it locally.
2. Next, analyze node_modules/ dir to see what is taking so much space there. I am guessing there will be a package that is taking a ton of space. If we managed to do step (1) above, then we can do this locally, it will be easier. If not, then we will have to do this measurement in the cloud. We should be looking into node_modules/ dirs in the .wasp/ I believe, there should be two of them, one for client, one for server. Maybe one for database. If you were using Wasp 0.13 there would also be one at the top level, but you are on 0.11 so there is none there (at least shouldn't be any).Wasp doesn't yet have proper "npm lock" / "dependency freeze" story in placeI've been under assumption that Wasp locks the deps, but if it's not the case - I'm 95% sure one of the deps (or multiple) got updated and causing this Got it, will try to find the root cause after the prod release. Thanks! ❤️
It does lock them somewhat, but not completely. In the sense that their patch versions can change. Normally that shouldn't cause any issues, but package maintainers sometimes make mistakes and while fixing one bug introduce another bug hah, and that happens more often than one would expect, so that is likely the cause.
Btw here is an issue for it, with a bit of background: https://github.com/wasp-lang/wasp/issues/559 .