Postgres database crashed after restart, tried just about everything including reinstalling postgres. It will not start on ubuntu 14.04,
$ systemctl status postgresql#9.6-main.service
Failed to issue method call: No such interface 'org.freedesktop.DBus.Properties' on object at path /org/freedesktop/systemd1/unit/postgresql_409_2e6_2dmain_2eservice
$ pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
9.6 main 5432 down postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log
$ sudo service postgresql start
* Starting PostgreSQL 9.6 database server
* Failed to issue method call: Unit postgresql#9.6-main.service failed to
load: No such file or directory. See system logs and 'systemctl status
postgresql#9.6-main.service' for details.
$ ps uxa|grep dbus-daemon
message+ 751 0.0 0.0 40812 4064 ? Ss 18:39 0:03 dbus-daemon --system --fork
dominic 3058 0.0 0.0 40840 4252 ? Ss 18:40 0:02 dbus-daemon --fork --session --address=unix:abstract=/tmp/dbus-S1LhlCDwl2
dominic 3145 0.0 0.0 39400 3536 ? S 18:40 0:00 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
dominic 17462 0.0 0.0 15956 2244 pts/4 S+ 21:45 0:00 grep --color=auto dbus-daemon
Postgres log file is empty.
I had the same error after install snap on Ubuntu 14.04. It was install some parts from systemd and broke postgresql init script.
You need to add parameter --skip-systemctl-redirect to pg_ctlcluster in file /usr/share/postgresql-common/init.d-functions
The function you need to change:
do_ctl_all() {
...
# --skip-systemctl-redirect fix postgresql No such interface 'org.freedesktop.DBus.Properties'
if [ "$1" = "stop" ] || [ "$1" = "restart" ]; then
ERRMSG=$(pg_ctlcluster --skip-systemctl-redirect --force "$2" "$name" $1 2>&1)
else
ERRMSG=$(pg_ctlcluster --skip-systemctl-redirect "$2" "$name" $1 2>&1)
fi
...
}
Ubuntu 14.04 did not switch to systemd yet. I highly recommend upgrading to 16.04 or even better, 18.04.
Related
I've googled and read quite a bit of blogs, posts, etc. on this. I've also been trying them out manually on my EC2 instance. However, I'm still not able to properly configure the systemd service unit to have it run the process in background as I expect. The process I'm running is nessus service. Here's my service unit definition:
$ cat /etc/systemd/system/nessusagent.service
[Unit]
Description=Nessus
[Service]
ExecStart=/opt/myorg/bin/init_nessus
Type=simple
[Install]
WantedBy=multi-user.target
and here is my script /opt/myorg/bin/init_nessus:
$ cat /opt/apiq/bin/init_nessus
#!/usr/bin/env bash
set -e
NESSUS_MANAGER_HOST=...
NESSUS_MANAGER_PORT=...
NESSUS_CLIENT_GROUP=...
NESSUS_LINKING_KEY=...
#-------------------------------------------------------------------------------
# link nessus agent with manager host
#-------------------------------------------------------------------------------
/opt/nessus_agent/sbin/nessuscli agent link --key=${NESSUS_LINKING_KEY} --host=${NESSUS_MANAGER_HOST} --port=${NESSUS_MANAGER_PORT} --groups=${NESSUS_CLIENT_GROUP}
if [ $? -ne 0 ]; then
echo "Cannot link the agent to the Nessus manager, quitting."
exit 1
fi
/opt/nessus_agent/sbin/nessus-service -q -D
When I run the service, I always get the following:
$ systemctl status nessusagent.service
● nessusagent.service - Nessus
Loaded: loaded (/etc/systemd/system/nessusagent.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Mon 2020-08-24 06:40:40 UTC; 9min ago
Process: 27787 ExecStart=/opt/myorg/bin/init_nessus (code=exited, status=0/SUCCESS)
Main PID: 27787 (code=exited, status=0/SUCCESS)
...
Aug 24 06:40:40 ip-10-27-0-104 init_nessus[27787]: + /opt/nessus_agent/sbin/nessuscli agent link --key=... --host=... --port=8834 --groups=...
Aug 24 06:40:40 ip-10-27-0-104 init_nessus[27787]: [info] [agent] HostTag::getUnix: setting TAG value to '8596420322084e3ab97d3c39e5c92e00'
Aug 24 06:40:40 ip-10-27-0-104 init_nessus[27787]: [info] [agent] Successfully linked to <myorg.com>:8834
Aug 24 06:40:40 ip-10-27-0-104 init_nessus[27787]: + '[' 0 -ne 0 ']'
Aug 24 06:40:40 ip-10-27-0-104 init_nessus[28506]: + /opt/nessus_agent/sbin/nessus-service -q -D
However, I can't see the process that I expect to see:
$ ps faux | grep nessus
root 28565 0.0 0.0 12940 936 pts/0 S+ 06:54 0:00 \_ grep --color=auto nessus
If I run the last command manually, I can see it:
$ /opt/nessus_agent/sbin/nessus-service -q -D
$ ps faux | grep nessus
root 28959 0.0 0.0 12940 1016 pts/0 S+ 07:00 0:00 \_ grep --color=auto nessus
root 28952 0.0 0.0 6536 116 ? S 07:00 0:00 /opt/nessus_agent/sbin/nessus-service -q -D
root 28953 0.2 0.0 69440 9996 pts/0 Sl 07:00 0:00 \_ nessusd -q
What is it that I'm missing here?
Eventually figured out that this was because of the extra -D option in the last command. Removing the -D option fixed the issue. Running the process in daemon mode inside a system manager is not the way to go. We need to run it in the foreground and let the system manager handle it.
I've been searching around a lot but could not figure out how to start mysqld in "safe mode".
This is what I got so far:
[root#localhost bin]# service mysqld_safe start
mysqld_safe: unrecognized service
I'm running CentOS, this is my mysql version:
[root#localhost ~]# mysql --version
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (i686) using readline 5.1
Any help would be appreciated!
Starting mysqld should do the trick:
[root#green-penny ~]# service mysqld start
Starting mysqld: [ OK ]
[root#green-penny ~]# ps axu | grep mysql
root 7540 0.8 0.0 5112 1380 pts/0 S 09:29 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql
mysql 7642 1.5 0.7 135480 15344 pts/0 Sl 09:29 0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
root 7660 0.0 0.0 4352 724 pts/0 S+ 09:29 0:00 grep mysql
(Note that mysqld_safe is running.)
I am trying to execute pg_dump on PostgreSQL 9.0.4 server running on Debian and I am getting the error below:
./pg_dump: error while loading shared libraries: libpq.so.5: cannot open shared object file: No such file or directory
libpq.so.5 is a link to libpq.so.5.3 as shown below
lrwxrwxrwx 1 root root 12 Jun 27 16:24 libpq.so.5 -> libpq.so.5.3
-rwxr-xr-x 1 root root 180749 Jun 21 02:43 libpq.so.5.3
What is it that I am doing wrong?
Try this:
1: Know the path of libpq.so.5
find / -name libpq.so.5
Output example:
/usr/pgsql-9.4/lib/libpq.so.5
If found nothing, check if you have already installed the suitable postgresql-libs for your postgresql version and your OS platform
2: Symbolic link that library in a "well known" library path like /usr/lib:
ln -s /usr/pgsql-9.4/lib/libpq.so.5 /usr/lib/libpq.so.5
Attention:
If your platform is 64 bit, you MUST also symbolic link to 64 bit libraries path:
ln -s /usr/pgsql-9.4/lib/libpq.so.5 /usr/lib64/libpq.so.5
3: Be happy !
In which directory are these libpq files? You can try setting environment variable LD_LIBRARY_PATH to point to this directory or make sure it's in standard place.
Also, why isn't the libpq.so.5 link shown in the "as shown below" section? Maybe you should just run ldconfig?
Ubuntu 21.10+
Since this is the top search result for the error. I'll add an updated answer. I received the error when trying to start a django server.
I hadn't installed the postgres stuff.
Try:
sudo apt install libpq-dev
See:
https://packages.ubuntu.com/impish/libpq-dev
I was getting the same error message on Postgres 9.5 on RHEL 6.5 which lead me to this post. But a find for the file libpq.so.5 returned nothing, which made things more confusing.
In the end the following symbolic links made it run
ln -s /opt/rh/rh-postgresql95/root/usr/lib64/libpq.so.rh-postgresql95-5 /usr/lib64/libpq.so.rh-postgresql95-5
ln -s /opt/rh/rh-postgresql95/root/usr/lib64/libpq.so.rh-postgresql95-5 /usr/lib/libpq.so.rh-postgresql95-5
These paths are for RHEL, use find / -name libpq.so to location your installation and add it to the same destination folders /usr/lib/ and /usr/lib64/ using the orginal file name.
The root cause appears that the installation did not place this file into a shared location.
This error probably occurs because of $LD_LIBRARY_PATH environment variable is not set.
When you install your application from source code using prefix (./configure --prefix=/some/path), you have to inform where your lib/ path is. I just found a solution for this, and I added this variable to postgres user init bash script:
printf 'export PATH=$PATH:/opt/apl/pgsql/bin\nexport LD_LIBRARY_PATH=/opt/apl/pgsql/lib:$LD_LIBRARY_PATH\n' > /etc/profile.d/postgres.sh
redhat 7 is missing few steps after installing yum install pgadmin4:
sudo ln -s /usr/lib64/pgdg-libpq5/lib/libpq.so /usr/lib64/libpq.so.5
sudo ln -s /usr/lib64/pgdg-libpq5/lib/libpq.so /usr/lib/libpq.so.5
sudo chown -R apache:apache /var/lib/pgadmin4/
then you can run
sudo python3 /usr/lib/python3.6/site-packages/pgadmin4-web/setup.py
and if all successful:
systemctl start httpd
systemctl status httpd
apachectl configtest
and make sure the httpd starts ok
I had exactly the same problem with the pg 9.6 install. I fixed it like this. Rather irritating that the installer doesn't factor this in.
***********post yum install & running initdb *********
Success. You can now start the database server using:
/opt/rh/rh-postgresql96/root/usr/bin/pg_ctl -D /var/opt/rh/rh-postgresql96/lib/pgsql/data -l logfile start
-bash-4.2$ /opt/rh/rh-postgresql96/root/usr/bin/pg_ctl -D /var/opt/rh/rh-postgresql96/lib/pgsql/data -l logfile start
/opt/rh/rh-postgresql96/root/usr/bin/pg_ctl: **error while loading shared libraries: libpq.so.rh-postgresql96-5: cannot open shared object file: No such file or directory**
-bash-4.2$ id
uid=26(postgres) gid=26(postgres) groups=26(postgres) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
**************
-bash-4.2$ cat LibFix
ln -s /opt/rh/rh-postgresql96/root/usr/lib64/libpq.so.rh-postgresql96-5 /usr/lib64/libpq.so.rh-postgresql96-5
ln -s /opt/rh/rh-postgresql96/root/usr/lib64/libpq.so.rh-postgresql96-5 /usr/lib/libpq.so.rh-postgresql96-5
**************
[root#****lab ~]# ln -s /opt/rh/rh-postgresql96/root/usr/lib64/libpq.so.rh-postgresql96-5 /usr/lib64/libpq.so.rh-postgresql96-5
[root#****lab ~]# ln -s /opt/rh/rh-postgresql96/root/usr/lib64/libpq.so.rh-postgresql96-5 /usr/lib/libpq.so.rh-postgresql96-5
[root#****lab ~]# su - postgres
Last login: Thu Apr 5 08:57:21 CEST 2018 on pts/0
-bash-4.2$ /opt/rh/rh-postgresql96/root/usr/bin/pg_ctl -D /var/opt/rh/rh-postgresql96/lib/pgsql/data -l logfile start
server starting
-bash-4.2$ ps -ef | grep postgres
root 12778 7883 0 09:07 pts/0 00:00:00 su - postgres
postgres 12779 12778 0 09:07 pts/0 00:00:00 -bash
postgres 12802 1 0 09:08 pts/0 00:00:00 /opt/rh/rh-postgresql96/root/usr/bin/postgres -D /var/opt/rh/rh-postgresql96/lib/pgsql/data
postgres 12803 12802 0 09:08 ? 00:00:00 postgres: logger process
postgres 12805 12802 0 09:08 ? 00:00:00 postgres: checkpointer process
postgres 12806 12802 0 09:08 ? 00:00:00 postgres: writer process
postgres 12807 12802 0 09:08 ? 00:00:00 postgres: wal writer process
postgres 12808 12802 0 09:08 ? 00:00:00 postgres: autovacuum launcher process
postgres 12809 12802 0 09:08 ? 00:00:00 postgres: stats collector process
postgres 12810 12779 0 09:08 pts/0 00:00:00 ps -ef
-bash-4.2$ id
uid=26(postgres) gid=26(postgres) groups=26(postgres) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
-bash-4.2$ psql
psql (9.6.5)
postgres=# \conninfo
You are connected to database "postgres" as user "postgres" via socket in "/var/run/postgresql" at port "5432".
I have postgresql running (/opt/local/lib/postgresql90/bin).
The data base is set up # /Users/demet8/postgres/data.
I check to make sure postgresql is running with
ps aux | grep postgres
demet8 9851 0.0 0.1 614276 1184 ?? Ss 12:40PM 0:00.24 postgres: autovacuum launcher process
demet8 9850 0.0 0.0 614020 436 ?? Ss 12:40PM 0:00.91 postgres: wal writer process
demet8 9849 0.0 0.0 614020 496 ?? Ss 12:40PM 0:01.22 postgres: writer process
demet8 9847 0.0 0.1 614020 2248 s002 S 12:40PM 0:00.61 /opt/local/lib/postgresql90/bin/postgres -D /Users/demet8/postgres/data
demet8 11127 0.0 0.0 599820 468 s002 S+ 2:05PM 0:00.00 grep postgres
demet8 9852 0.0 0.0 610092 368 ?? Ss 12:40PM 0:00.26 postgres: stats collector process
I go back into: /opt/local/lib/postgresql90/bin & now try to start the db with ./pg_ctl start. This is the error msg I get:
pg_ctl: no database directory specified and environment variable PGDATA unset
Try "pg_ctl --help" for more information.
Any suggestions on to what I can be doing wrong. I googled around the web for answers & I haven't found a solution.
$ su -
# su - postgres
Proceed from there.
I know this question is already answered but, if you are new to Postgres and seeing similar issues, try the below commands to resolve the error pg_ctl: no database directory specified and environment variable PGDATA unset Try "pg_ctl --help" for more information.
1. su - postgres
2. find / -name pg_ctl --> gives you the location where pg_ctl present, in my case it is there in `/usr/lib/postgresql/11/bin/`
3. /usr/lib/postgresql/11/bin/pg_ctl -D /var/lib/postgresql/11/main
I'm running my rails app in production mode and in staging mode on the same server, in different folders. They both use memcache-client which requires memcached to be running.
As yet i haven't set up a deploy script and so just do a deploy manually by sshing onto the server, going to the appropriate directory, updating the code, restarting memcached and then restarting unicorn (the processes which actually run the rails app). I restart memcached thus:
sudo /etc/init.d/memcached restart &
This starts a new memcached, but it doesn't kill the old one: check it out:
ip-<an-ip>:test.millionaire[subjects]$ ps afx | grep memcache
11176 pts/2 S+ 0:00 | \_ grep --color=auto memcache
10939 pts/3 R 8:13 \_ sudo /etc/init.d/memcached restart
7453 ? Sl 0:00 /usr/bin/memcached -m 64 -p 11211 -u nobody -l 127.0.0.1
ip-<an-ip>:test.millionaire[subjects]$ sudo /etc/init.d/memcached restart &
[1] 11187
ip-<an-ip>:test.millionaire[subjects]$ ps afx | grep memcache
11187 pts/2 T 0:00 | \_ sudo /etc/init.d/memcached restart
11199 pts/2 S+ 0:00 | \_ grep --color=auto memcache
10939 pts/3 R 8:36 \_ sudo /etc/init.d/memcached restart
7453 ? Sl 0:00 /usr/bin/memcached -m 64 -p 11211 -u nobody -l 127.0.0.1
[1]+ Stopped sudo /etc/init.d/memcached restart
ip-<an-ip>:test.millionaire[subjects]$ sudo /etc/init.d/memcached restart &
[2] 11208
ip-<an-ip>:test.millionaire[subjects]$ ps afx | grep memcache
11187 pts/2 T 0:00 | \_ sudo /etc/init.d/memcached restart
11208 pts/2 R 0:01 | \_ sudo /etc/init.d/memcached restart
11218 pts/2 S+ 0:00 | \_ grep --color=auto memcache
10939 pts/3 R 8:42 \_ sudo /etc/init.d/memcached restart
7453 ? Sl 0:00 /usr/bin/memcached -m 64 -p 11211 -u nobody -l 127.0.0.1
What might be causing it is there's another memcached running - see the bottom line. I'm mystified as to where this is from and my instinct is to kill it but i thought i'dd better check with someone who actually knows more about memcached than i do.
Grateful for any advice - max
EDIT - solution
I figured this out after a bit of detective work with a colleague. In the rails console i typed CACHE.stats which prints out a hash of values, including "pid", which i could see was set to the instance of memcached which wasn;t started with memcached restart, ie this process:
7453 ? Sl 0:00 /usr/bin/memcached -m 64 -p 11211 -u nobody -l 127.0.0.1
The memcached control script (ie that defines the start, stop and restart commands), is in /etc/init.d/memcached
A line in this says
# Edit /etc/default/memcached to change this.
ENABLE_MEMCACHED=no
So i looked in /etc/default/memcached, which was also set to ENABLE_MEMCACHED=no
So, this was basically preventing memcached from being stopped and started. I changed it to ENABLE_MEMCACHED=yes, then it would stop and start fine. Now when i stop and start memcached, it's the above process, the in-use memcached, that's stopped and started.
try using:
killall memcached