Re: Can't restart Postgres

On 02/15/2017 09:03 AM, Shawn Thomas wrote:
> /usr/lib/postgresql/9.4/bin/pg_ctl: No such file or directory
>
> postgres(at)pangaea:/usr/lib/postgresql/9.4/bin$ ls -al
> total 4008
> drwxr-xr-x 2 root root 4096 Feb 9 16:17 .
> drwxr-xr-x 3 root root 4096 Feb 9 16:17 ..
> -rwxr-xr-x 1 root root 68128 Nov 16 06:53 clusterdb
> -rwxr-xr-x 1 root root 68192 Nov 16 06:53 createdb
> -rwxr-xr-x 1 root root 63920 Nov 16 06:53 createlang
> -rwxr-xr-x 1 root root 72672 Nov 16 06:53 createuser
> -rwxr-xr-x 1 root root 63936 Nov 16 06:53 dropdb
> -rwxr-xr-x 1 root root 63920 Nov 16 06:53 droplang
> -rwxr-xr-x 1 root root 63904 Nov 16 06:53 dropuser
> -rwxr-xr-x 1 root root 68416 Nov 16 06:53 pg_basebackup
> -rwxr-xr-x 1 root root 351904 Nov 16 06:53 pg_dump
> -rwxr-xr-x 1 root root 2186504 Nov 16 06:53 pg_dumpall
> -rwxr-xr-x 1 root root 30992 Nov 16 06:53 pg_isready
> -rwxr-xr-x 1 root root 47600 Nov 16 06:53 pg_receivexlog
> -rwxr-xr-x 1 root root 51928 Nov 16 06:53 pg_recvlogical
> -rwxr-xr-x 1 root root 154944 Nov 16 06:53 pg_restore
> -rwxr-xr-x 1 root root 515320 Nov 16 06:53 psql
> -rwxr-xr-x 1 root root 68160 Nov 16 06:53 reindexdb
> -rwxr-xr-x 1 root root 72384 Nov 16 06:53 vacuumdb
>
> As I mentioned, this Debian package removes pg_ctl from the bin directory and instead attempts to wrap the pg_ctl functionality in a perl script so that the PG process is integrated with systemd. I really wish they hadn’t, and it’s part of the reason I’m where I’m at.

Ubuntu uses the same setup and I see it, see below.

The Perl script just redirects commands to the correct version of
Postgres and uses that versions binaries.

aklaver(at)arkansas:~$ uname -a
Linux arkansas 4.8.6-x86_64-linode78 #1 SMP Tue Nov 1 14:51:21 EDT 2016
x86_64 x86_64 x86_64 GNU/Linux
aklaver(at)arkansas:~$ l /usr/lib/postgresql/9.4/bin/
total 8388
drwxr-xr-x 2 root root 4096 Feb 9 07:24 ./
drwxr-xr-x 4 root root 4096 Sep 29 2015 ../
-rwxr-xr-x 1 root root 68096 Feb 8 07:04 clusterdb*
-rwxr-xr-x 1 root root 68160 Feb 8 07:04 createdb*
-rwxr-xr-x 1 root root 63888 Feb 8 07:04 createlang*
-rwxr-xr-x 1 root root 72640 Feb 8 07:04 createuser*
-rwxr-xr-x 1 root root 63904 Feb 8 07:04 dropdb*
-rwxr-xr-x 1 root root 63888 Feb 8 07:04 droplang*
-rwxr-xr-x 1 root root 63872 Feb 8 07:04 dropuser*
-rwxr-xr-x 1 root root 114296 Feb 8 07:04 initdb*
-rwxr-xr-x 1 root root 26624 Feb 8 07:04 oid2name*
-rwxr-xr-x 1 root root 18432 Feb 8 07:04 pg_archivecleanup*
-rwxr-xr-x 1 root root 68416 Feb 8 07:04 pg_basebackup*
-rwxr-xr-x 1 root root 64600 Feb 8 07:04 pgbench*
-rwxr-xr-x 1 root root 30792 Feb 8 07:04 pg_config*
-rwxr-xr-x 1 root root 30720 Feb 8 07:04 pg_controldata*
-rwxr-xr-x 1 root root 43320 Feb 8 07:04 pg_ctl*
-rwxr-xr-x 1 root root 355968 Feb 8 07:04 pg_dump*
-rwxr-xr-x 1 root root 89320 Feb 8 07:04 pg_dumpall*
-rwxr-xr-x 1 root root 30960 Feb 8 07:04 pg_isready*
-rwxr-xr-x 1 root root 47568 Feb 8 07:04 pg_receivexlog*
-rwxr-xr-x 1 root root 51928 Feb 8 07:04 pg_recvlogical*
-rwxr-xr-x 1 root root 38920 Feb 8 07:04 pg_resetxlog*
-rwxr-xr-x 1 root root 154912 Feb 8 07:04 pg_restore*
-rwxr-xr-x 1 root root 22536 Feb 8 07:04 pg_standby*
-rwxr-xr-x 1 root root 22648 Feb 8 07:04 pg_test_fsync*
-rwxr-xr-x 1 root root 14416 Feb 8 07:04 pg_test_timing*
-rwxr-xr-x 1 root root 113168 Feb 8 07:04 pg_upgrade*
-rwxr-xr-x 1 root root 51672 Feb 8 07:04 pg_xlogdump*
-rwxr-xr-x 1 root root 5993920 Feb 8 07:04 postgres*
lrwxrwxrwx 1 root root 8 Feb 8 07:04 postmaster -> postgres*
-rwxr-xr-x 1 root root 519384 Feb 8 07:04 psql*
-rwxr-xr-x 1 root root 68128 Feb 8 07:04 reindexdb*
-rwxr-xr-x 1 root root 72352 Feb 8 07:04 vacuumdb*
-rwxr-xr-x 1 root root 22528 Feb 8 07:04 vacuumlo*

>
> -Shawn
>
>
>
>> On Feb 15, 2017, at 8:49 AM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>>
>> On 02/15/2017 08:35 AM, Shawn Thomas wrote:
>>> Yes, that’s the correct sequence of scripts. And no there’s not anything really helpful in the system logs.
>>>
>>> I’m thinking that at this point I need to approach this problem as more of a disaster recovery. There was a full pg_dumpall file that was deleted and cannot be recovered so I need to recover the data from the /var/lib/postgresql/9.4/main directory. I believe this is called a file level recovery. I assume I need to use a fully functional, same version PG (on another machine?) to create a full dump of the data directory. Once I have this I can re-install Postgres on the initial server and read the databases back into it.
>>>
>>> Any advice on how to best go about this? The official documentation seems a bit thin:
>>>
>>> https://www.postgresql.org/docs/9.4/static/backup-file.html
>>>
>>> I’ve only worked with normal (pg_dump, pg_dumpall) backups in the past.
>>
>> Shawn
>>
>> As the postgres user:
>>
>> /usr/lib/postgresql/9.4/bin/pg_ctl -D /var/lib/postgresql/9.4/main start
>>
>> What returns?
>>
>> Sincerely,
>>
>> JD
>>
>>
>> --
>> Command Prompt, Inc. http://the.postgres.company/
>> +1-503-667-4564
>> PostgreSQL Centered full stack support, consulting and development.
>> Everyone appreciates your honesty, until you are honest with them.
>> Unless otherwise stated, opinions are my own.
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com