Обсуждение: Re: Problems invoking psql. Help please.
Does "Could not execv" mean that I do not have rights to execute this script? >biko:/usr/bin# ls -al | grep psql >lrwxrwxrwx 1 root root 10 Oct 10 16:24 psql -> pg_wrapper >biko:/usr/bin# This seems to say that Other users, like postgres, should be able to execute it. I'm confused, here. -- Hugh I did this tonight dpkg --purge postgresql apt-get install postgresql and am now still getting the following: >biko:/usr/bin# psql -U postgres >No database specified >biko:/usr/bin# psql -U postgres template1 >Could not execv /usr/lib/postgresql/bin/psql >biko:/usr/bin# psql -U postgres template0 >Could not execv /usr/lib/postgresql/bin/psql >biko:/usr/bin# psql -U postgres ggp_test >Could not execv /usr/lib/postgresql/bin/psql >biko:/usr/bin# My pg_hba.conf temporarily reads: >local all trust >host all 127.0.0.1 255.255.255.255 trust >host template1 192.168.2.21 255.255.255.0 trust >host all 0.0.0.0 0.0.0.0 reject (Eventually, before I take this live, I'll figure out the crypt part). The postgresql installation is at 192.168.10. I'm working from a shell at 192.168.2.21. But I also tried running this from the application server at 2.10 as well and got the same errors. And now pgAdmin II is giving me a connection error: >An error has occured in pgAdmin II:frmConnect.cmdConnect_Click >Number -2147467259 >Description: Could not connect to the server; >Could not connect to remote socket. /etc/postgresql/postgresql.conf includes a line reading: >tcpip_socket = 1 which I assume means that I _should_ be able to make a TCP connection across the network. Although I cannot seem to do so. Working in Debian 3.0 Woody, with postgreSQL 7.2. Still looking for clues, in fact I seem to be looking for more clues now than I was yesterday. -- Hugh At 05:20 PM 11/19/02 +0000, you wrote: >Did you install your package using apt-get ? >All the instalations that I do are using those tools from debian. You have >to see all the packages that you have instaled in your computer like: > >dpkg -l | grep postgresql >ii postgresql 7.2.1-2 Object-relational SQL database, descended fr >ii postgresql-cli 7.2.1-2 Front-end programs for PostgreSQL >ii postgresql-con 7.2.1-2 Additional facilities for PostgreSQL > >Then you do: dpkg --purge postgresql. You can now run the first command to >see if something is still installed. If some are instaled, the you remove >it using again dpkg --purge. > >Luis Sousa > >Hugh Esco wrote: > >>I have reinstalled before. I wonder though, how I ensure that I have >>cleanly un-installed it first, so that I leave no residue from the >>previously botched installation around to mess things up the next time. >> >>-- Hugh Esco >> >>At 09:03 AM 11/19/02 +0000, Luis Sousa wrote: >> >>>Tom Lane wrote: >>>Start over: delete your PG installation and reinstall the Debian >>>package. It seems very clear that you've got an incomplete package. >>>regards, tom lane >>>I agree with Tom Lane. Probably is the best thing to do. When you >>>install all it over, in theory, all the problems will solve by them selfs. >>> >>>Luis Sousa
Hugh Esco <hesco@greens.org> writes:
>> biko:/usr/bin# ls -al | grep psql
>> lrwxrwxrwx 1 root root 10 Oct 10 16:24 psql -> pg_wrapper
> This seems to say that Other users, like postgres, should be able to
> execute it. I'm confused, here.
The permissions attached to a symbolic link are meaningless, in all Unix
variants I've dealt with. You need to look at the permissions of the
linked-to object (here, pg_wrapper) instead...
regards, tom lane
That is indeed true. Also I see you do everything as root, try creating a new user especially for postgres databases. create a directory with root in /usr/loca/pgsql/ named data, or any other directory that is in $PGDATA. chown the directory to the postgres user, log in as the postgres user and try to initdb, postmaster (-i!) and connect... I think the problem lies here somewhere... Michiel At 02:13 20-11-2002 -0500, Tom Lane wrote: >Hugh Esco <hesco@greens.org> writes: > >> biko:/usr/bin# ls -al | grep psql > >> lrwxrwxrwx 1 root root 10 Oct 10 16:24 psql -> pg_wrapper > > > This seems to say that Other users, like postgres, should be able to > > execute it. I'm confused, here. > >The permissions attached to a symbolic link are meaningless, in all Unix >variants I've dealt with. You need to look at the permissions of the >linked-to object (here, pg_wrapper) instead... > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
My continued appreciation to Tom Lane, Michael Lange, Luis Sousa and Cameron Spitzer: Apologies for the length of this, but I've tried everything suggested and most f this is the shell dialogues of when I did so. At 08:40 AM 11/20/02 +0100, Michiel wrote: >That is indeed true. Also I see you do everything as root, try creating a >new user especially for postgres databases. create a directory with root >in /usr/loca/pgsql/ named data, or any other directory that is in $PGDATA. >chown the directory to the postgres user, log in as the postgres user and >try to initdb, postmaster (-i!) and connect... I think the problem lies >here somewhere... > >Michiel Actually I tend to use the postgres user for all of this stuff. I'm not sure why my prompt does not indicate that to be the case. Two shells working, in the first I did: >postgres@biko:/usr/local$ su >Password: >biko:/usr/local# mkdir pgsql >biko:/usr/local# cd pgsql/ >biko:/usr/local/pgsql# mkdir data >biko:/usr/local/pgsql# ls -al >total 12 >drwxr-sr-x 3 root staff 4096 Nov 20 02:55 . >drwxrwsr-x 15 root staff 4096 Nov 20 02:54 .. >drwxr-sr-x 2 root staff 4096 Nov 20 02:55 data >biko:/usr/local/pgsql# chown postgres:postgres data >biko:/usr/local/pgsql# ls -al >total 12 >drwxr-sr-x 3 root staff 4096 Nov 20 02:55 . >drwxrwsr-x 15 root staff 4096 Nov 20 02:54 .. >drwxr-sr-x 2 postgres postgres 4096 Nov 20 02:55 data >biko:/usr/local/pgsql# su postgres >biko:/usr/local/pgsql$ In the second shell, this was the dialogue: >biko:/usr/lib/postgresql/bin$ whoami >postgres >biko:/usr/lib/postgresql/bin$ ./initdb -D /usr/local/pgsql/data >The files belonging to this database system will be owned by user "postgres". >This user must also own the server process. > >Fixing permissions on existing directory /usr/local/pgsql/data... ok >creating directory /usr/local/pgsql/data/base... ok >creating directory /usr/local/pgsql/data/global... ok >creating directory /usr/local/pgsql/data/pg_xlog... ok >creating directory /usr/local/pgsql/data/pg_clog... ok >creating template1 database in /usr/local/pgsql/data/base/1... ok >creating configuration files... ok >initializing pg_shadow... ok >enabling unlimited row size for system tables... ok >creating system views... ok >loading pg_description... ok >vacuuming database template1... ok >copying template1 to template0... ok > >Success. You can now start the database server using: > > ./postmaster -D /usr/local/pgsql/data >or > ./pg_ctl -D /usr/local/pgsql/data -l logfile start > >biko:/usr/lib/postgresql/bin$ ./postmaster -i -D /usr/local/pgsql/data This is different from how I used to invoke the postmaster, but seems to work nonetheless. This sequence has permitted me to access the template0 database from pgAdmin II on my Windows desktop box again. However, when I again attempt to invoke the psql client, I get this: >biko:/usr/bin$ ls -al | grep pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 createdb -> pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 createuser -> >pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 dropdb -> pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 dropuser -> pg_wrapper >lrwxrwxrwx 1 root root 10 Nov 19 20:04 pg_config -> >pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 pg_dump -> pg_wrapper >lrwxrwxrwx 1 root root 10 Nov 19 20:04 pg_restore -> >pg_wrapper >-rwxr-xr-x 1 root root 6584 Sep 11 04:30 pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 psql -> pg_wrapper >biko:/usr/bin$ ./psql -U postgres template1 >Could not execv /usr/lib/postgresql/bin/psql >biko:/usr/bin$ ./psql -U postgres template0 >Could not execv /usr/lib/postgresql/bin/psql >biko:/usr/bin$ Following Louise Sousa's advice, here is what I saw: >biko:/usr/bin$ whoami >postgres >biko:/usr/bin$ psql template1 >Could not execv /usr/lib/postgresql/bin/psql >biko:/usr/bin$ psql -h biko >No database specified >biko:/usr/bin$ psql -h biko template1 >Could not execv /usr/lib/postgresql/bin/psql >biko:/usr/bin$ I got the same results when I changed my pg_hba.conf file to read: >local all trust >#host all 127.0.0.1 255.255.255.255 trust >host all 192.168.2.21 255.255.255.0 trust >host all 0.0.0.0 0.0.0.0 reject Invoking SQLedger does permit me to Create Dataset, but my attempt to login to that dataset gets the following error: >SELECT version FROM defaults >ERROR: Relation "defaults" does not exist And looking back to the pgAdmin II client, I see that the databases created by SQLedger seem to exist, but are X'd out and their tables and other objects are inaccessible. Cameron suggested I should also reinstall postgresql-client: >biko:/usr/bin# whoami >root >biko:/usr/bin# apt-get install postgresql-client >Reading Package Lists... Done >Building Dependency Tree... Done >Sorry, postgresql-client is already the newest version. >0 packages upgraded, 0 newly installed, 0 to remove and 36 not upgraded. >biko:/usr/bin# So I am at a loss and still encountering the same errors as before; except that I used to be able to access the tables and objects of the model dataset created by SQLedger and now I can't. Any other ideas out there? -- Hugh Esco >At 02:13 20-11-2002 -0500, Tom Lane wrote: >>Hugh Esco <hesco@greens.org> writes: >> >> biko:/usr/bin# ls -al | grep psql >> >> lrwxrwxrwx 1 root root 10 Oct 10 16:24 psql -> >> pg_wrapper >> >> > This seems to say that Other users, like postgres, should be able to >> > execute it. I'm confused, here. >> >>The permissions attached to a symbolic link are meaningless, in all Unix >>variants I've dealt with. You need to look at the permissions of the >>linked-to object (here, pg_wrapper) instead... >> >> regards, tom lane
Mr. Lane: pg_wrapper permits Others to Execute it. >biko:/usr/bin$ ls -al | grep pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 createdb -> pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 createuser -> >pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 dropdb -> pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 dropuser -> pg_wrapper >lrwxrwxrwx 1 root root 10 Nov 19 20:04 pg_config -> >pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 pg_dump -> pg_wrapper >lrwxrwxrwx 1 root root 10 Nov 19 20:04 pg_restore -> >pg_wrapper >-rwxr-xr-x 1 root root 6584 Sep 11 04:30 pg_wrapper >lrwxrwxrwx 1 root root 10 Oct 10 16:24 psql -> pg_wrapper >biko:/usr/bin$ At 02:13 AM 11/20/02 -0500, Tom Lane wrote: >Hugh Esco <hesco@greens.org> writes: > >> biko:/usr/bin# ls -al | grep psql > >> lrwxrwxrwx 1 root root 10 Oct 10 16:24 psql -> pg_wrapper > > > This seems to say that Other users, like postgres, should be able to > > execute it. I'm confused, here. > >The permissions attached to a symbolic link are meaningless, in all Unix >variants I've dealt with. You need to look at the permissions of the >linked-to object (here, pg_wrapper) instead... > > regards, tom lane
On Wed, 2002-11-20 at 13:52, Hugh Esco wrote: > However, when I again attempt to invoke the psql client, I get this: > >biko:/usr/bin$ ./psql -U postgres template1 > >Could not execv /usr/lib/postgresql/bin/psql Pay attention to the exact message and do not flounder around aimlessly. There is no reason to be messing about with pg_hba.conf. You have some kind of system problem here. execv() is a system call to run another executable in place of the current process. If the other executable is not present, or does not have permissions, you will not be able to run it. Find out why. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "If my people, which are called by my name, shall humble themselves, andpray, and seek my face, and turn from their wicked ways; then will I hear from heaven, and will forgive theirsin, and will heal their land." II Chronicles 7:14
Oliver Elphick <olly@lfix.co.uk> writes:
> execv() is a system call to run another executable in place of the
> current process. If the other executable is not present, or does not
> have permissions, you will not be able to run it. Find out why.
Aside from access problems for the executable itself, it could be that
there's a shared-library access problem. Perhaps ldconfig needs to be
told where libpq.so is?
regards, tom lane
On Wed, 2002-11-20 at 15:03, Tom Lane wrote: > Oliver Elphick <olly@lfix.co.uk> writes: > > execv() is a system call to run another executable in place of the > > current process. If the other executable is not present, or does not > > have permissions, you will not be able to run it. Find out why. > > Aside from access problems for the executable itself, it could be that > there's a shared-library access problem. Perhaps ldconfig needs to be > told where libpq.so is? It's not the error message you would get for that: olly@linda$ sudo mv /usr/lib/libpq.so.2 /usr/lib/libpq.so.2.bak Password: olly@linda$ psql -d bray /usr/lib/postgresql/bin/psql: error while loading shared libraries: libpq.so.2: cannot open shared object file: No such file or directory -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "If my people, which are called by my name, shall humble themselves, andpray, and seek my face, and turn from their wicked ways; then will I hear from heaven, and will forgive theirsin, and will heal their land." II Chronicles 7:14