On 02/15/2017 03:09 PM, Shawn Thomas wrote:
Just wanted to follow up that re-installing Postgres worked (well almost—I did
have to reset the permissions and ownership on the key and pem file).
Thanks so much for all the help.
That's what we are here for :D
Sincerely,
JD
-Shawn
--
Just wanted to follow up that re-installing Postgres worked (well almost—I did
have to reset the permissions and ownership on the key and pem file).
Thanks so much for all the help.
-Shawn
> On Feb 15, 2017, at 9:49 AM, Adrian Klaver wrote:
>
> On 02/15/2017
Yes, definitely.
> On Feb 15, 2017, at 9:49 AM, Adrian Klaver wrote:
>
> On 02/15/2017 09:45 AM, Shawn Thomas wrote:
>> Which would you recommend? Leave the data directory in place and
>> re-install PG or copy it to somewhere else, delete it and then
>> re-install
Yes, sadly it does explain things. Your insight has been super helpful though.
-Shawn
> On Feb 15, 2017, at 9:38 AM, Adrian Klaver wrote:
>
> On 02/15/2017 09:28 AM, Shawn Thomas wrote:
>> Well that would make more sense of things. I had removed and
>> re-installed
On 02/15/2017 09:45 AM, Shawn Thomas wrote:
Which would you recommend? Leave the data directory in place and
re-install PG or copy it to somewhere else, delete it and then
re-install PG?
I would copy the data directory somewhere else for safe keeping leaving
the original in place. Then
Which would you recommend? Leave the data directory in place and re-install PG
or copy it to somewhere else, delete it and then re-install PG?
-Shawn
> On Feb 15, 2017, at 9:36 AM, Magnus Hagander wrote:
>
> On Wed, Feb 15, 2017 at 6:28 PM, Shawn Thomas
I was responsible for deleting/re-inatalling the cert. I was attempting to get
Shibboleth (a federated authentication service that also uses the cert) running
and didn’t realize that PG relied on it.
The dumpAll file wasn’t actually deleted but was empty. I’ll look into that
mystery once I
On 02/15/2017 09:28 AM, Shawn Thomas wrote:
Well that would make more sense of things. I had removed and
re-installed the postresql-common package:
https://packages.debian.org/jessie/postgresql-common
Well that is the glue that holds the pgcluster scheme together. Also
when I try it I get:
On Wed, Feb 15, 2017 at 6:28 PM, Shawn Thomas
wrote:
> Well that would make more sense of things. I had removed and re-installed
> the postresql-common package:
>
> https://packages.debian.org/jessie/postgresql-common
>
> and thought that it would leave the main PG
Well that would make more sense of things. I had removed and re-installed the
postresql-common package:
https://packages.debian.org/jessie/postgresql-common
and thought that it would leave the main PG package in place. But perhaps I
was wrong. I’ll follow Tom’s advice and just re-install
On 02/15/2017 09:28 AM, Joshua D. Drake wrote:
On 02/15/2017 09:17 AM, Adrian Klaver wrote:
On 02/15/2017 09:03 AM, Shawn Thomas wrote:
/usr/lib/postgresql/9.4/bin/pg_ctl: No such file or directory
That should have been:
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
On 02/15/2017 09:17 AM, Adrian Klaver wrote:
On 02/15/2017 09:03 AM, Shawn Thomas wrote:
/usr/lib/postgresql/9.4/bin/pg_ctl: No such file or directory
That should have been:
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.2 LTS
Release:
On 02/15/2017 09:03 AM, Shawn Thomas wrote:
/usr/lib/postgresql/9.4/bin/pg_ctl: No such file or directory
postgres@pangaea:/usr/lib/postgresql/9.4/bin$ ls -al
total 4008
drwxr-xr-x 2 root root4096 Feb 9 16:17 .
drwxr-xr-x 3 root root4096 Feb 9 16:17 ..
-rwxr-xr-x 1 root root
On 02/15/2017 09:03 AM, Shawn Thomas wrote:
/usr/lib/postgresql/9.4/bin/pg_ctl: No such file or directory
That should have been:
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.2 LTS
Release:16.04
Codename: xenial
--
Adrian
On 02/15/2017 09:03 AM, Shawn Thomas wrote:
/usr/lib/postgresql/9.4/bin/pg_ctl: No such file or directory
postgres@pangaea:/usr/lib/postgresql/9.4/bin$ ls -al
total 4008
drwxr-xr-x 2 root root4096 Feb 9 16:17 .
drwxr-xr-x 3 root root4096 Feb 9 16:17 ..
-rwxr-xr-x 1 root root
> On Feb 14, 2017, at 8:47 PM, Shawn Thomas wrote:
>
> No it doesn’t matter if run with sudo, postgres or even root. Debian
> actually wraps the command and executes some some initial scripts with
> different privileges but ends up making sure that Postgres ends up
Shawn Thomas writes:
> 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
>
On Wed, Feb 15, 2017 at 6:03 PM, Shawn Thomas
wrote:
> /usr/lib/postgresql/9.4/bin/pg_ctl: No such file or directory
>
> postgres@pangaea:/usr/lib/postgresql/9.4/bin$ ls -al
> total 4008
> drwxr-xr-x 2 root root4096 Feb 9 16:17 .
> drwxr-xr-x 3 root root
/usr/lib/postgresql/9.4/bin/pg_ctl: No such file or directory
postgres@pangaea:/usr/lib/postgresql/9.4/bin$ ls -al
total 4008
drwxr-xr-x 2 root root4096 Feb 9 16:17 .
drwxr-xr-x 3 root root4096 Feb 9 16:17 ..
-rwxr-xr-x 1 root root 68128 Nov 16 06:53 clusterdb
-rwxr-xr-x 1
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
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
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
On 02/14/2017 08:47 PM, Shawn Thomas wrote:
No it doesn’t matter if run with sudo, postgres or even root. Debian
actually wraps the command and executes some some initial scripts with
different privileges but ends up making sure that Postgres ends up
running under the postgres user. I get the
Sent from my iPad
> On Feb 14, 2017, at 9:47 PM, Shawn Thomas wrote:
>
> No it doesn’t matter if run with sudo, postgres or even root. Debian
> actually wraps the command and executes some some initial scripts with
> different privileges but ends up making sure
No it doesn’t matter if run with sudo, postgres or even root. Debian actually
wraps the command and executes some some initial scripts with different
privileges but ends up making sure that Postgres ends up running under the
postgres user. I get the same output if run with sudo:
sudo
On 02/14/2017 05:00 PM, Adrian Klaver wrote:
On 02/14/2017 12:00 PM, Shawn Thomas wrote:
Yes that would be the standard approach. But the Debian package removes
pg_ctl from it normal place and wraps it with a perl script in a way
that makes it difficult to work with (it doesn’t accept the same
On 02/14/2017 12:00 PM, Shawn Thomas wrote:
Yes that would be the standard approach. But the Debian package removes
pg_ctl from it normal place and wraps it with a perl script in a way
that makes it difficult to work with (it doesn’t accept the same arguments):
Shawn Thomas writes:
> I inadvertently deleted the ssl-cert-snakeoil.pem out from under a running
> Postgres instance (9.4) which caused it to shut down. The last line of
> main.log:
> FATAL: could not load server certificate file
>
Yes that would be the standard approach. But the Debian package removes pg_ctl
from it normal place and wraps it with a perl script in a way that makes it
difficult to work with (it doesn’t accept the same arguments):
https://wiki.debian.org/PostgreSql#pg_ctl_replacement
Il 14/02/2017 20:31, Joshua D. Drake ha scritto:
On 02/14/2017 11:17 AM, Shawn Thomas wrote:
I inadvertently deleted the ssl-cert-snakeoil.pem out from under a
running Postgres instance (9.4) which caused it to shut down. The
last line of main.log:
FATAL: could not load server certificate
On Tue, Feb 14, 2017 at 8:47 PM, Joshua D. Drake
wrote:
> On 02/14/2017 11:43 AM, Shawn Thomas wrote:
>
>> pangaea:/var/log# systemctl status postgresql
>> ● postgresql.service - PostgreSQL RDBMS
>>Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
>>
On 02/14/2017 11:43 AM, Shawn Thomas wrote:
pangaea:/var/log# systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
Active: active (exited) since Tue 2017-02-14 10:48:18 PST; 50min ago
Process: 28668
pangaea:/var/log# systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
Active: active (exited) since Tue 2017-02-14 10:48:18 PST; 50min ago
Process: 28668 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
On 02/14/2017 11:17 AM, Shawn Thomas wrote:
I inadvertently deleted the ssl-cert-snakeoil.pem out from under a running
Postgres instance (9.4) which caused it to shut down. The last line of main.log:
FATAL: could not load server certificate file
"/etc/ssl/certs/ssl-cert-snakeoil.pem": No
I inadvertently deleted the ssl-cert-snakeoil.pem out from under a running
Postgres instance (9.4) which caused it to shut down. The last line of main.log:
FATAL: could not load server certificate file
"/etc/ssl/certs/ssl-cert-snakeoil.pem": No such file or directory
I've since restored the
I think I must have only done a reload on the live server as now I've
tried to restart the service and I've got exactly the same error, so
it's no longer a discrepancy between environments.
The script is actually one which came with the Gentoo package. I can
see it is using both $PGOPTS and
I myself noticed that if a client is still connected to the DB server,
then PgSQL won't restart. Are you sure all your clients are/were
disconnected? I myself have the DB on remote a virtual machine.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
Well that can't really be the problem since it isn't running when
trying to start.
But yes, I've noticed that before which I actually find very useful.
It's a shame there isn't a way for postgres to broadcast to clients
that it wants to shutdown so things like pgAdmin III will say Hey,
the
Thom Brown [EMAIL PROTECTED] writes:
The script is actually one which came with the Gentoo package.
...
Okay, so I've manually tried starting the server now and told it to
output any log to /tmp. This is telling me that the request for a
shared memory segment is higher than my kernel's
Hi,
I've got a development virtual server which matches live exactly
except for the fact that Postgres is running on a different port which
is not used by anything else. Postgres was running fine until I
updated postgresql.conf to enhance logging and make better use of
system resources.
Here's
Thom Brown wrote:
Hi,
I've got a development virtual server which matches live exactly
except for the fact that Postgres is running on a different port
What do you mean by virtual server? And does it affect definitions of
localhost or shared-memory allocation?
which
is not used by
Hi,
Did you check permissions?
Do the pid files exist?
What variables are set?
Regards,
Serge Fonville
On Wed, Oct 29, 2008 at 4:43 PM, Thom Brown [EMAIL PROTECTED] wrote:
Hi,
I've got a development virtual server which matches live exactly
except for the fact that Postgres is running on a
Permissions are identical to live. I've checked the /tmp folder for a
PID reference, but doesn't exist in live or dev.
What do you mean by variables? How can I check?
I only have one postgresql database cluster on each server.
With regards to the config causing memory problems, the specs of
On Wed, Oct 29, 2008 at 9:43 AM, Thom Brown [EMAIL PROTECTED] wrote:
Hi,
* Forcing it to shutdown which leads to a recover-run on next startup.
pg_ctl: PID file /var/lib/postgresql/8.3/data/postmaster.pid does not exist
Is server running?
* Forced shutdown failed!!! Something is wrong with
Actually I did ps aux | grep post just to cover all bases, but still
nothing.. except of course the grep itself.
On Wed, Oct 29, 2008 at 6:38 PM, Scott Marlowe [EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 9:43 AM, Thom Brown [EMAIL PROTECTED] wrote:
Hi,
* Forcing it to shutdown which
Thom Brown [EMAIL PROTECTED] writes:
Actually I did ps aux | grep post just to cover all bases, but still
nothing.. except of course the grep itself.
The overwhelming impression from here is of a seriously brain-dead
startup script. It's spending all its effort on being chatty and none
on
46 matches
Mail list logo