Ticket: Port 3000 Initialization Failure in Database Setup
@zapoqx Just created a ticket
Question: Something is wrong with initializing Port 3000 into the database.
Attempted: I intiailly tried using my synology nas to make the containers. I learned I couldn't use port 5432 so I tried switching that port and I changed the volumes. Everything seems to work, but on check, much like the post found here: https://discord.com/channels/1243410146097500202/1297914286001361008 I would get a 502 error on making the login. After messing with several settings and trying a few things, I couldn't get a solution going so I decided to try seeing if it was possible to go more default to the docker compose installation by setting up on a blank raspberry pi 5 with just portainer and watchtower. Took longer than the synology drive, but it was up, though the exact same error still comes up and port 3000 fails to initialize so its making me think its not just about a specific platform as something is causing port 3000 to fail to initialize. Perhaps the Caddy built-in may not be working right or the prisma isn't wanting to connect. Attached displays the error that comes up, but note that the port has been tested inside the container to see if it can be pinged which it can, so something is preventing the connection.
Working On: Depends on whether we are talking on the Raspberry Pi 5 or a Synology Nas.
Take it from here @Postiz
Question: Something is wrong with initializing Port 3000 into the database.
Attempted: I intiailly tried using my synology nas to make the containers. I learned I couldn't use port 5432 so I tried switching that port and I changed the volumes. Everything seems to work, but on check, much like the post found here: https://discord.com/channels/1243410146097500202/1297914286001361008 I would get a 502 error on making the login. After messing with several settings and trying a few things, I couldn't get a solution going so I decided to try seeing if it was possible to go more default to the docker compose installation by setting up on a blank raspberry pi 5 with just portainer and watchtower. Took longer than the synology drive, but it was up, though the exact same error still comes up and port 3000 fails to initialize so its making me think its not just about a specific platform as something is causing port 3000 to fail to initialize. Perhaps the Caddy built-in may not be working right or the prisma isn't wanting to connect. Attached displays the error that comes up, but note that the port has been tested inside the container to see if it can be pinged which it can, so something is preventing the connection.
Working On: Depends on whether we are talking on the Raspberry Pi 5 or a Synology Nas.
Take it from here @Postiz
261 Replies
Attached is the error that is shown where it cannot connect to the database.
Do you use the normal docker? it's actually try to proxy everything to port 5000
As I said, I did it as per initial guide of docker compose, but through portainer. The Synology method literally cannot do 5432 for whatever reason and that was the only reason I changed as similar to the other post. But to also not work for the same reason based more on the original code with a Raspberry Pi is what got me questioning.
or did you mean did I try switching to docker standalone?
besides, if I did docker standalone, looking at the information, the issue would be the same thing, is it not? Standalone contains Caddy still.
saw there was an update, did a quick check, same error still at exact same spot.
Heya
Yeah, synology usese port 5432 already for the database
Do you need you change the Postgres post in your configuration
So, instead of;
Do this;
I did already.
it is still focused on the port 3000 issue with the error.
the overall is it doesn't matter what is done on ports for the postgresql database, the port 3000 that is set by caddy will refuse to connect to the database and it doesn't matter even how direct I guess. I left it to "postiz-postgres" and I changed it to "localhost" and even went with the local network that came up (i.e. if network was set to 172.16.1.4, then I set it as such for that database), it just gives the error as from the attached log (replacing "localhost:5432" with whatever combination that it was pointed to).
So, it's not picking up the changed DATABASE_URL then? Are you using Docker Compose? If so, did you do docker compose down and up again?
Continuing on from other thread:
I'm confused, why is the internal Caddy an issue? Let's go back to basics, can you explain your setup?
Here is the base problem... by documentation going by this:
https://docs.postiz.com/installation/docker-compose
the Postiz Container has an internal Proxy by Caddy.
From following along with the launch of the logs, the container does its thing to start to get everything ready.
Prisma is used for the Database which I understand.
So before anything happens, the database all launch and Caddy has to make and connect the services.
Thus from the attached message, what I'm saying is during the creation time, it successfully makes Frontend Service a connected source. However, the Docker-compose.yml example that is provided shows nothing about port 4200, not that it is required to be opened for the docker's sake or anything like that. If I wasn't looking at the document, I would have no idea that there is a port 4200 even called. So moving past that, 4200 is successful and creates the front end that any setup that has a domain name with HTTPS 443 setup to go to the reverse proxy of the http at port 5000 (or theoretically any port that you create at that time for the docker that you can configure) HAS to go through a secondary internal reverse proxy with Caddy that as the coder has zero control over. So we can acknowledge from that point on the Frontend, it creates and is successfully connected.
Then Prisma has to use Caddy to make a connection to the backend. Before it can even try to creat the connection, it errors talking about
you may have to run $[qe("prisma generate")] for your changes to take effect.
Due to that error, it seems it will always fail to try to connect to any postgres port, which in turn will make Caddy fail to connect to port 3000.
My idea is, much like 5432 being consumed by Synology, what if the error is more about the port itself being consumed still by something else. Hence why I tried to use a Raspberry Pi with nothing but Portainer setup to do a docker compose. Portainer has one port used and nothing more. 5432 default will work on the Pi cause that pi literally has nothing (though it takes forever to compose). However, it too will have the exact same error when trying to launch Prisma with Caddy. So unless there is a lock on a port somewhere OR there is an extra dependency that for whatever reason isn't being generated on 2 different hardware (1 being Synology but with x86 architecture, 1 with ARM), then its not going to matter what is being used unless I attempt something like the document that mentions a VM Ubuntu setup which seems a bit absurd.
So I wanted to try to have Caddy separated out or something to where I can manually check if its a port issue or if its Prisma itself and what in Prisma is causing the error to generate? As long as Prisma errors AFTER the successful creation of port 4200 with connection to front end but before it can even try to connect to the database, it will fail.
Also, I realized in there that even if you changed the port of the internal URL according to the end of the log, that code of BACKEND_INTERNAL_URL: "http://localhost:3000" is pointless to mess with because from my assumption, internal caddy is hardcoded to port 3000.as an aside, I also checked the Docker (standalone) version, and it at least does have port configuration which I assume is just exposing port 4200 and port 3000 in the docker itself for the connection, though it seems like more of a "what purpose" if Docker Compose does not have that configuration. So hoping that there would be some kind of different error, I tried exposing those ports manually in Docker Compose and still the exact same error comes up. So Prisma is failing somehow, but I cannot figure out how or why its failing before that connection is made, yet it seems to be successful with the frontend port without issue.
and since its not easy to get the logs I want to post... here it is from start of postiz container:
and no, 2 of the images is not posted twice, it errors twice in the log.
oh and just as a Double checking element, I can go into the postiz container itself and do a ping check on the created network for the database to ensure it can be reached from Postiz' container. So it can't be a connection error in which it cannot connect to.
My question is
Prisma’s connection is needed before Caddy is fully initialized?
I did see something about postgres could need a timeout delay to connect and while I tried to see if I could change that in the URL, it didn't seem to matter. So would that be more of a hardcode in the container itself?
You tried
connect_timeout=x
yep
Same error?
yep
increased it questioning if it was by ms count, tried to put in a value that should be 1 minute, but the error still comes up and there didn't seem to be a delay of any sort.
So, no, Caddy is just handling incomming traffic
Prisma is the bit that connects to the Postgres database
(connects out from Postiz to Postgres)
So, your postgres is probably not running on localhost right, if you're running docker compose
"localhost" in the container means "local to the container"
Your DATABASE_URL should probably have "postiz-postgres" as the server name
as opposed to... network localhost
done that
did it original
changed it to localhost thinking to go with network localhost
still same error
Did you do "docker compose down" after changing the values in your docker-compose.yml?
portainer does it automatically when updating the value
to save it that is
ah okay dokey
I've not used portainer yet, but does it have the ability to get a terminal inside the container easily?
portainer has a knack of giving errors at the right time to know if there is an issue with the code itself.
yep
Okay, go do that, let's do some debugging
Can you run the command
env | grep -i DATABASE for me inside the container, and show me the screenshot of the output?give me a sec.
No worries
so you want it in the postiz container or the postgres portion of the container?
Inside the Postiz container please 🙂
realized I put in a different user name and password just to see if it needed to be done so censored that.
hmm, that's interesting, so it certainly looks like that is correct for the hostname
Now can you run
nc -vz postiz-postgres:5439 for me?k. nothing returned... guess I'll check the logs?
nothing changed in logs either
hmm, that means it cannot connect to that server on that port - nc is "net cat"
Did you deliberately start the Postgres container on a different port? The default is 5432
I do see them in their own network container under currently 172.22.0.X
on synology yes
Ah right, as something on Synology uses that port already?
I believe its own app has something on that port which is why it fails
Sure, sure.
Let's try redis;
on raspberry pi, I can confirm default port does not error on creation of the container, but still has same error which was why I was questioning something
nc -vz postiz-redis 6379ok
postiz-redis:6379 (172.22.0.3:6379) openOkay dokey, that's good!
So let's go look at your postgres container, I assume Portainer says that is running all OK?
everything is healthy
Can you get a shell on that container as well?
yep
currently in
apt-get update && apt-get install iproute2
and then;
huh... I was already questioning if I could do that but got my answer in typing.
but maybe that command might still work
ok I was hopeful
Yeah, I want to see is Postgres is listening on the right port properly. We want to see a line like;
apt-get isn't found in the postgres container
kinda makes sense
oh, it is there in the postgres container we recommend
What image is that container using?
image: postgres:17-alpineook someone changed that lol
Bro did you allow "trust" in
pg_hba.conf
Okay, no problem
apk add iproute2 should work
I'm assuming the alpine image does that by default
but I'll check that, at the moment we've got no network connection to postgres, so we'll troubleshoot that later if it's an issueok, yep, that did it...
Okay dokey, your postgres is listening on the default port inside the container, all good
So now, let's take a look at the "ports" definition of the container in Portainer
It should be
5439:5432 hopefullyerm
I don't have a portainer installation to check, so maybe a screenshot of that or whatever?
no? I did same to same
Ah, theres your problem then 🙂
hrm...
Inside the container, it's running port 5432, that's fine, as it's not listening publicly on your synology
However you want to access it on a different external port (5439), so you change that in the port mapping
So, in Portainer, change the port assignment to "5439:5432", and restart the Postgres container.
ok, but then in theory, should it have worked out the gate then on the raspberry pi when the port wasn't changed and it was 1:1 on the port (5432:5432)
k, making the change.
Sure - you're talking about two different servers here right, the synology and a rpi?
yea
I mean hey, I gotta try all avenues before reporting my problems
Okay, well we could possibly fix that rpi later, but let's just keep to one server for now otherwise things will get confusing 🙂
Did you manage to change the port assignment and restart the postiz-postres container now?
also tends to take 2.5 minutes on a pi to get any updates done. Anyways... its up... looking at logs
no
error still there
Okay, don't worry about the logs right now, we'll need to restart Postiz in a minute anyway
Get a terminal back on the Postiz container
and run
nc -vz postiz-postgres:5439 for me
Hopefully we'll see a "open" message.negative
insert sad music
Okay, what do you see instead?
its a simple return?
Like, no output?
like I'd appreciate something even if there is no value to return but it looks more like a script execution at that point
no verbose
anyways, enough of my rambling.
hmm, so that's very odd, here's what you should see
right and it would make sense
Just incase, try a space between the host and port, incase it doesn't like the :
still no
Okay, let's check something that obviously should work;
nc -vz google.com 80
and also; ping postiz-postgresOkay, and the ping?
huh.
confused face
I do agree though that if this is solved, then in theory it should resolve on any other platform using portainer
Okay, so here's where we are, postiz cannot apply the database migrations because it cannot talk to the database. We thought it was a closed port / wrong port, and found it was, and we changed it. You can ping from the app to teh database, but it's still unable to talk to the database on that port.
correct
Okay, can you ssh do the server running Portainer for me now, and run
docker inspect postiz-postgres | grep -i port -B 5well I gotta open the SSH port for that first.
^^ I was just stating where we'd got to, just making sure you knew where we were.
Ah sorry :-(, is that OK to do?
prefer not to for too long but yes.
Thanks, I need to validate that the Postgres container really is running on the right port.
but that is my internal security side of me screaming.
SSH itself is very secure 🙂
oh yea, but its the possibility of it being seen is why it screams
anyways
interesting
?
I have a guess that Portainer is cheating you 😛
Ah, I assume you're not root -
sudo su?Bro when did you last restart your Synology?
unless I need to sudo.
Yeah, docker requires root.
actually 3 days ago 🙂
ok, let me try that again.
Okay, damn, that looks like the right port.
I'm confused why
nc is not giving you any output though.i'd love to at least have some kind of verbose log to why but...
Okay, well that is a bit of a mystery, but at least the container appears to be running on the right port.
correct
Just while you're there,
docker inspect postiz-app | grep -i networkmodeYeah no blame to candy
er, should it be postiz?
Sorry, yep
Okay, all good there. I don't think there's anything else we need to test from here, you can close that SSH session and block SSH again if you like.
Let's try a full restart of Postiz, and have a full read of it's startup logs.
I need you to do effectively a
docker compose down postiz and docker compose up postiz if you can do the same as that from the Portainer web interface, and then see the logs from the startup
Importantly I want you to recreate that Postiz container (which compose down / compose up will do)hmmm
so I have it as a Stack in portainer so effectively doing manually would make them their own containers rather than grouped.
Okay, basically we want to make sure the Postiz container is deleted and created again new. Do you have to stop the whole stack and then restart the whole stack again?
I'm excited to see culprit
Or, stop, delete, start?
I'm gonna brb 10 mins
well yes, I do, but when you mentioned just the container, I went to the container itself to see if I can simply recreate it while being part of the stack. Never tried it that way, but seeing
welp...
Again
Okay, so at least it's definately trying to get to the right address.
Let's see if Portainer is doing something funny with networking, can you get a shell on the postiz-postgres container please?
Then run
apk add nc && nc -vz postiz 5000postiz (172.22.0.4:5000) openOkay, phew
So the DB can talk to the app (specifically, caddy)
But the app can't talk to the DB
correct
Let's sanity check again, let's get a terminal back on the postiz container
nc -vz postiz-postgres 5432 (should not work) and nc -vz postiz-postgres 5439 (should work, but didn't before)wait what
I know your confusion
Yes 5432
err
confused face
what lol
Bro you need a quick reboot i think
What's your OS
No no, don't reboot
I can, but I don't think its gonna change anything.
Nah, I don't think so either.
Also, in the off chance that it does, we don't want to reset the state of everyting
*everything
Did you check you might be running some other containers in background
So, I'm confused, we checked that postiz-postgres container definition, we saw it was running in port 5439, however nc is saying that it's not, and it's running in port 5432 - the default
I wondered if it's actually getting to the postgres on your synology, but it's not, because 172.22.0.2 is deffo a container IP
.3 is your pi ?
Actually, can you check the IP address of the postiz-postgres container? Validate that it really is 172.22.0.2?
I'd also like to point out that error, while currently on Synology (7.2.1), and earlier, I mentioned I did the same setup but more default on a Raspberry Pi 5, both were restarted at the same time, but the exact error that comes up is the only common point.
Yeah, you real error is this;
It goes on to try and start Postiz later, but that won't work because of the previous error.
exactly
so something is specific to this container itself (imo)
but trust me, as also done QA work before and annoyed devs to no end, I'm honestly enjoying this trying to figure out the why me approach here.
Again just to checkpoint where we are, I don't see anything like a Postiz or Postgres bug or anything here, we're just dealing with a basic network problem, where the app isn't connecting to the database - because weirdly the DB looks like it's running on the wrong port.
Correctly set
^^ No problem, I'm a dev and I've done a lot of sysadmin, just as long as we follow one thing at a time and keep communicating I'll help you all night 😄
But I am properly confused as to why the container is on the "wrong" port.
That's why I asked
Okay, let's see, can you get the current IP address of the postiz-postgres container? Let's validate that really is 172.22.0.2
well lets just make it easy with this:
(I added 4200 and 3000 to postiz just as an experiment)
Sure, port 5000 is what we really want, not 4200 or 3000, but they're not causing problems
Everything there looks sane to me
But this does not look sane, I am very confused.
😶
I get what you're asking, but I don't know what you're talking about there as trusting a file from where to what?
if you're asking from the folder for the container, I didn't set any specific things yet as I didn't see anything specific that required any specialty permissions
It's just a config file of postgresql to allow network
hm
I don't think that's the problem here, if that was not setup correctly we'd probably get a connection denied when connecting to postgres, not connection unreachable. However, I'm currently not quite sure what to try.
Let's get a shell on the postiz-postgres container, and run;
tail -n 15 /var/lib/postgresql/data/pg_hba.confYes you are right boss
normally I would find something in a docker-capable app if it needs special permissions so
this is default on its own
That's good
But still we have some network issue here lol
brb few mins
With that, I need a few min break myself. 10 min
Yeah, that all looks normal.
Sure, speak in 10.
Update
back
ready whenever you are
Sorry, didn't see that you came back 🙂
no worries
So, the postiz-postgres container is still not accessible on the expected port 5439, but is on 5432.
yep
My instinct is that the container port mapping isn't working, but we checked that on the running container with the
docker inspect, and it showed a host port of 5439.
Like all these things, I bet it's something very simple actually. It's a typo that we're not seeing, or similar.
Can you dump me your current running docker-compose again please? Let me check that, top to bottom.let me sanitize it slightly
Sure thing, most important really is the social media API keys - don't post them obviously.
oh I didn't get there yet to know fully about that when I couldn't make an account which is where we all started XD
Okay let's have a read
It's not related here, but note that
PUID and PGID won't work in the postiz image.
Those are LSIO (linuxserver.io) conventions.Got used to it was all
No worries.
You also don't need;
ya had that added in just in case if it made a difference before today
but removed
hmm, it all looks fine though
Okay, I'm going to try and run this on a clean VM myself
k
OK! I have the same error with your docker compose
on one hand... excellent
That's very good, I can debug much easier this way
It's okay, I didn't want to sleep tonight 😛
Hah
who knows, I may not sleep much myself.
Same behavior;
been cleaning up to put a new monitor in.
It's going to be a typo somewhere I'm betting
hmmm k
so at least you can replicate it
ohhh I wonderrrrrrrr
???
Yeah I think I've got it, just fixing something with my https setup to check I can create a user
k
Okay, so, I learned something about docker compose this evening.
The problem is that "ports" is ignored in this context
I... wat
Because they're all on the same network - the "ports" part is for connecting ports on the host to the container
Hey bro try
test: ["CMD", "pg_isready", "-U", "pguser", "-d", "wdblocal"]
Instead
test: pg_isready -U pguser -d wdblocal
However, for container to container networking, it's ignored
Ooooh
On a technical level, containers in docker compose is the same newwork share the same "network" namespace, but not the same "uts" namespace
Meaning they each have their own localhost, and hostnames
O_O
And they'd each have their own IP address as well (that happens anyway)
🫠
But they're all sharing the same ports
so localhost in one container in this context is not the same as localhost in another container
Or on a technical level, the same "port namespace"
Yeah, because they have separate "uts" namespaces
Docker thing
I was looking for a localhost within the network, but really was looking within this defined space >_>
So, the solution to your problem is actually ridicuslously simple, and I should update the docker compose examples
Now I can sleep in peace 🕊️✌️
Simply use port "5432" in DATABASE_URL
and remove "ports" for the postgres container and redis container - they're not actually being used at all
Infact, it's actually a security issue, because it's exposing them on the "external" network when they don't need to be
ok
uggh
Thanks for your patience this evening/this afternoon
GN
Let me know of course if that works - but just on the postiz container;
and set "5432" in DATABASE_URL
and stop/recreate/start everything
understood
should I still add the code change:
test: ["CMD", "pg_isready", "-U", "pguser", "-d", "wdblocal"]Try if you don't get it run
But I think it will perfectly run
There's a
healthcheck: defined on the postiz-postgres container anywaywoah
guess its time to test if I can actually make an account then
It worked bro 😅
lol it went through cleanly in the logs yes, only having this pop up:
wooop
Yeah I need to fix that, it can safely be ignored
I think for now you can ignore that warning ⚠️
Yeah I added it in months ago when we were depending on CloudFlare
Nice I learned something new today
Docker Sucks 😂
Wellllll, I've been using Docker since 2015 when it was basically pre 1.0, and I never knew this worked like it did 😄 However I don't use docker-compose much.
and technically I don't use Docker much, I use podman/cri-o
hah so solved one problem, into another
but I mean we're passed this point at least
And I have been using it since 2023
This is the things we learn while solving bugs 🐛
Unless you'd like to, I'd like to update the otehr ticket so that Klaus fellow can actually have progress on his end too.
Ah, set
EMAIL_FROM_ADDRES and EMAIL_FROM_NAME, that's why you're getting that error messagehe probably didn't set a nodemailer (I was just trying that in the documentation when I found out about it)
I'll add that to the docker compose docs too, now I'm editing them
nah, it's specificlaly those 2 variables - here's the code;
Look into .env now
ah, EMAIL_FROM_NAME and EMAIL_FROM_ADDRESS are in the email docs already
yea that was probably my mistake.
I'll just change it to "must be set"
only so much to try when you have nothing to work with XD
hah, yes of course 🙂
I assume you're all logged in now?
not yet
gotta redo db
cause of trapped e-mail
to activate
ah, and note that because you have email set, yeah, you'll have to do user activation
We can hack the DB if it's a pain
nah
I'd rather just get it at least clean to start
Nice 🙂
ah it did send good
Right, it's 1:15am here, I've just pushed doc changes for docker-compose and the emails, to hopefully prevent this happening to other people again (port 5432 will no longer be needed on the host, reducing chances of a conflict).
I guess once I get in, I'll start to learn the rest
and adding APIs as wanted through the docs
uh one last thing
I know it said in the docs to use Option A, B, or C for the Docker Compose
can you mix?
If you can register without an error message, it shows that the database connection and backend service are working at least 🙂
like if we're talking about adding APIs like I saw in the ENV example
Yes, you can mix, that's fine, but I'd strongly recommend just keeping everything in the docker-compose.
makes sense
I back it up anyways
so just define them as is
Otherwise you start asking "hmm, where was that environment varable set, which one has precedence" ,etc
hah yea
I can see myself doing that too
We're moving away from environment variables for all the configuration as well
Apart from DATABASE_URL
ah good
I'm building a settings editor, etc, so make stuff like email configuration and provider configuration all pointy and clicky, copy and paste into text boxes.
er
whoops
looks like I wasn't out of the woods yet
and may be my fault with my mailfilter
hmm? No activation email?
I think my mailfilter activated before I did
but now the page just keeps refreshing back to login
so can't get in
my mailfilter has a nasty habit of pre-checking links to make sure there is nothing malicious when its a first e-mail from anything
even if the domain itself is "trusted"
Okay, I'm not sure what that is, and I haven't actually gone through the user activation flow via email before (Nevo wrote that) - I can read through the code tomorrow, but for now I need to go to bed!
I'd recommend disabling email for now just to get things working maybe?
sounds good
have a good night!
Not sure if a new ticket should be made, but yea, I tested sending an e-mail by registering another account on another e-mail and it oddly goes to the signup page. If I click the link again, it says I already activated the account. If I try to login... the page looks like it refreshes, but nothing happens. I checked the logs and nothing new came up. Just to make sure logs was clean, I restarted it and tried logging in again and it just refreshes. To be sure it was working, I tried putting in an account name that shouldn't exist which it does end up erroring that there isn't an account, so using the credentials made from either account, nothing happens other than a refresh of the page.
Just wanted to check if you had some time to check today?
@zapoqx , sorry, I didn't - I spent most of the evening coding Postiz instead
Worked on a new responsive UI; https://github.com/gitroomhq/postiz-app/pull/416
GitHub
feature: Responsive launches UI by jamesread · Pull Request #416 · ...
TODO: Writing description - come back in a few mins
This PR introduces a functional responsive UI for at least the "launches" part of the web interface, which is obviously the mos...
I'm in UK timezone, I know you're Pheonix Timezone, we can speak tomorrow maybe - I'm just heading to bed, it's 2am for me!
Ok. Understood!
been busy most of the day @xcons so apologies for not reaching out.
@xcons still not quite in after updating to the newest version. Signin just refreshes.
and also, this one is the one that relates: https://discord.com/channels/1243410146097500202/1303035017446031492/1303488927574917191