You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL;DR: pg_isready only seems to work when executed interactively in the pod, as opposed to when the pod is executed. This happens after I had to manually add the PGSSLMODE=require env variable because it was throwing a /root/.postgresql/postgresql.crt: Permission denied error.
After just setting the env variables listed above (MODE=MANUAL, MANUAL_RUN_FOREVER=FALSE, CONTAINER_ENABLE_SCHEDULING, and CONTAINER_ENABLE_MONITORING), it wouldn't start on its own (was waiting on user input).
Adding /etc/services.available/10-db-backup/run to the "command" field of the container definition resulted in a "no such file or directory" error.
I took inspiration from this comment which had me add the ['/init', 'backup-now'] commands which worked.
At that point, with all the envs loaded, I was getting a failed connection to my postgres server with /root/.postgresql/postgresql.crt: Permission denied being cited as the issue.
I added PGSSLMODE=require to the env list, and the error went away.
Now, I am facing the issue where pg_isready won't see that the server is ready. In order to debug, I grabbed the command that was being executed in the debug logs and ran it interactively in the pod with pg_isready --host=$DB01_HOST --port=$DB01_PORT --dbname=$DB01_NAME --username=$DB01_USER and it worked perfectly.
I suspect that this is a permissions issue with how the commands are being executed, but I'm not entirely sure.
update: I see that the path listed in this part of the readme is incorrect, and it should be /etc/services.available/dbbackup-01/run instead of /etc/services.available/10-db-backup/run. At least, that's what is in my docker image.
It's now able to execute "run" as was mentioned in the docs, but it's still stuck at the pg_isready not working in an automated fashion.
Summary
TL;DR:
pg_isready
only seems to work when executed interactively in the pod, as opposed to when the pod is executed. This happens after I had to manually add thePGSSLMODE=require
env variable because it was throwing a/root/.postgresql/postgresql.crt: Permission denied
error.Steps to reproduce
What I did was I:
MODE=MANUAL
,MANUAL_RUN_FOREVER=FALSE
,CONTAINER_ENABLE_SCHEDULING
, andCONTAINER_ENABLE_MONITORING
), it wouldn't start on its own (was waiting on user input)./etc/services.available/10-db-backup/run
to the "command" field of the container definition resulted in a "no such file or directory" error.['/init', 'backup-now']
commands which worked./root/.postgresql/postgresql.crt: Permission denied
being cited as the issue.PGSSLMODE=require
to the env list, and the error went away.pg_isready
won't see that the server is ready. In order to debug, I grabbed the command that was being executed in the debug logs and ran it interactively in the pod withpg_isready --host=$DB01_HOST --port=$DB01_PORT --dbname=$DB01_NAME --username=$DB01_USER
and it worked perfectly.I suspect that this is a permissions issue with how the commands are being executed, but I'm not entirely sure.
I have the following k8s config:
What is the expected correct behavior?
pg_isready sees that the server is up and backs it up
Relevant logs and/or screenshots
I've attached the debug logs with everything sensitive scrubbed: private-logs.txt
Environment
Possible fixes
I've spent a fair amount of time debugging this, so I felt like there was just a point where it would be best to track my progress with a bug open
The text was updated successfully, but these errors were encountered: