I'm running Debian unstable, and I keep getting a message from a
cron job that wants to do.maintenance about no password being
supplied.
Password:
psql: fe_sendauth: no password supplied

Now, I gather in the past a person had to explicitly put a
password in the cron job, but we are now supposed to use a file
called ~/.pgpass (~ being /var/lib/postgres). Well, I do have
such a file, so I am confused as to why I keep getting this error
message from the cron job. Five colon separated fields
hostort:*:userassword
are in this file. Host is localhost, port is 5432, .... I must
be missing something simple, but I don't see it.

Gord



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

<ghaverla (AT) freenet (DOT) edmonton.ab.ca> writes:
That is the recommended solution, but I'll bet that the cron job is not
running with the same value of $HOME that you think it is, and so it is
failing to find the file. You might want to explicitly set $HOME in the
script.

Also, test the .pgpass file by manually running psql with it; if there
is something wrong with the file contents you'll be able to prove it...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Thu, 1 Jul 2004, Tom Lane wrote:
Well, neither the cron script nor /etc/postgresql/postgresql.env
(which is sourced by the cron script) explicitly set $HOME. But
the message from cron indicates that home is /var/lib/postgres
and the user is postgres when the script runs.

X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/var/lib/postgres>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=postgres>

Well, if I 'su - postgres' from root, and then run
'psql template1' everything works fine. I suppose I could edit
the .pgpass to contain a bad password, and see if psql fails. If
I put a bad password in .pgpass, the attempt to try psql fails.
So, psql is using .pgpass.

Gord


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

<ghaverla (AT) freenet (DOT) edmonton.ab.ca> writes:
Hm. Given that you seem to have eliminated other possibilities,
I guess I'd question that message. Have you tried putting something
like "env > logfile" into the cron script to directly verify what
environment it gets?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Thu, 2004-07-01 at 18:26, ghaverla (AT) freenet (DOT) edmonton.ab.ca wrote:
I suggest you edit /usr/lib/postgresql/bin/do.maintenance and add a line
set -x
at line 2. Then you will be able to see exactly what command it is
trying to run.

--
Oliver Elphick olly (AT) lfix (DOT) co.uk
Isle of Wight http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA
========================================
"Therefore being justified by faith, we have peace with
God through our Lord Jesus Christ." Romans 5:1


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

On Fri, 2 Jul 2004, Oliver Elphick wrote:

++ /usr/bin/psql -q -X -t -d template1 -P border=0 -c '
SELECT datname
FROM pg_database
WHERE datallowconn
ORDER BY datname'
Password:
psql: fe_sendauth: no password supplied
+ dblist=
+ IFS=

+ /usr/bin/psql -d template1 -t -q -X
Password:
psql: fe_sendauth: no password supplied

My guess is it is that -X (disallow reading of a .psqlrc file) is
somehow turning off the reading of any .pgpass file.

Gord


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

On Sun, 2004-07-04 at 20:41, ghaverla (AT) freenet (DOT) edmonton.ab.ca wrote:
I can't see how that could be. -X is a psql option, but .pgpass is read
by the libpq library, which has no knowledge of the psql options.

Can you check that do.maintenance is being run by the correct user? (Put
the line "user identity = `id`" somewhere near the top.) Also, see if
do.maintenance works when run directly rather than through cron.

--
Oliver Elphick olly (AT) lfix (DOT) co.uk
Isle of Wight http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA
========================================
"Therefore being justified by faith, we have peace with
God through our Lord Jesus Christ." Romans 5:1


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Sun, 4 Jul 2004, Oliver Elphick wrote:
Well, -X is one of the few switches common to both commands.
Reading .pgpass seems to me, to be some kind of initialization
thing. That is all I based me guess on.

I already have the output of env in the cron script. According to
that, it is postgres that it is being run as.

X-Cron-Env: <HOME=/var/lib/postgres>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=postgres>
....
HOME=/var/lib/postgres
SHLVL=2
LOGNAME=postgres
....


But, we'll check that too.

Gord


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Oliver Elphick <olly (AT) lfix (DOT) co.uk> writes:
I don't believe it either --- libpq will always look for a $HOME/.pgpass
file.

A couple of possibilities that I don't think have been considered yet:

1. Old libpq? .pgpass is only supported in 7.3 and later. Even if
your psql is 7.3, I think it might be possible for the dynamic linker
to bind a 7.2 libpq.so to it, if your ldconfig search path is such
that the older libpq.so is found first.

2. Bad permissions on .pgpass? libpq will silently ignore a .pgpass
file it cannot open for reading. It will not-so-silently ignore
a .pgpass file that has any group or world permissions. I'm not
sure if you are capturing stderr from the psql run; if not, it's
possible the latter case is occurring and we're just not seeing
the bleat...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Sun, 4 Jul 2004, Tom Lane wrote:
Well, I'm as up to date as debian/unstable is. Almost every day I
do the apt-get update/upgrade thing. My libpq.so.3 is from
7.4.3-1 in terms of Debian.


Well, the permissions of .pgpass are 600 owned by postgres in
group postgres. The permissions on /var/lib/postgres are 755 with
it owned by postgres, in group postgres.

And the cron script is telling us the user is postgres, so there
should be no problems reading the file.

What's next, modify the call to psql in do.maintenance by putting
it in a strace?

Gord


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly