Unable to start postgresql.service?
OP seems to be using RHEL7 or CentOS7, as indicated by the systemctl commands. If so, the service . restart commands won’t work.
Finally, I figured this one out. There was already a file present
/usr/lib/systemd/system/postgresql-9.6.service So, may be due to the presence of this file, I was not able to start postgresql.service. Then I tried to start postgresql-9.6.service as follows:
[code_master5@BitBox ~]$ sudo systemctl start postgresql-9.6.service Failed to start postgresql-9.6.service: Unit postgresql-9.6.service not found. And, as you can see the output, again it failed.
I simply deleted the file using sudo as I thought may be postgresql.service file is not being created by relevant program due to the presence of this file. Then I restarted the system. It’s working fine since then, as you can see the output below:
[code_master5@BitBox ~]$ sudo systemctl status postgresql.service [sudo] password for code_master5: ● postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor p Active: active (running) since Sat 2017-01-28 09:31:30 IST; 7h ago Main PID: 342 (postgres) Tasks: 6 (limit: 4915) CGroup: /system.slice/postgresql.service ├─342 /usr/bin/postgres -D /var/lib/postgres/data ├─358 postgres: checkpointer process ├─359 postgres: writer process ├─360 postgres: wal writer process ├─361 postgres: autovacuum launcher process └─362 postgres: stats collector process Jan 28 09:31:26 BitBox systemd[1]: Starting PostgreSQL database server. Jan 28 09:31:28 BitBox postgres[340]: FATAL: the database system is starting up Jan 28 09:31:28 BitBox postgres[340]: LOG: database system was shut down at 201 Jan 28 09:31:29 BitBox postgres[340]: FATAL: the database system is starting up Jan 28 09:31:29 BitBox postgres[340]: LOG: MultiXact member wraparound protecti Jan 28 09:31:29 BitBox postgres[340]: LOG: database system is ready to accept c Jan 28 09:31:29 BitBox postgres[340]: LOG: autovacuum launcher started Jan 28 09:31:30 BitBox systemd[1]: Started PostgreSQL database server. I would surely like to warn all those having same problem. Please do whatever I did at your own risk. Since these are system files. Messing with these can spoil your weekend!
I am still a bit confused on this though. Explanations are welcome!
Postgresql not starting linux
Before anyone can access the database, you must start the database server. The database server program is called postgres .
If you are using a pre-packaged version of PostgreSQL , it almost certainly includes provisions for running the server as a background task according to the conventions of your operating system. Using the package’s infrastructure to start the server will be much less work than figuring out how to do this yourself. Consult the package-level documentation for details.
The bare-bones way to start the server manually is just to invoke postgres directly, specifying the location of the data directory with the -D option, for example:
$ postgres -D /usr/local/pgsql/data which will leave the server running in the foreground. This must be done while logged into the PostgreSQL user account. Without -D , the server will try to use the data directory named by the environment variable PGDATA . If that variable is not provided either, it will fail.
Normally it is better to start postgres in the background. For this, use the usual Unix shell syntax:
$ postgres -D /usr/local/pgsql/data >logfile 2>&1 & It is important to store the server’s stdout and stderr output somewhere, as shown above. It will help for auditing purposes and to diagnose problems. (See Section 25.3 for a more thorough discussion of log file handling.)
The postgres program also takes a number of other command-line options. For more information, see the postgres reference page and Chapter 20 below.
This shell syntax can get tedious quickly. Therefore the wrapper program pg_ctl is provided to simplify some tasks. For example:
will start the server in the background and put the output into the named log file. The -D option has the same meaning here as for postgres . pg_ctl is also capable of stopping the server.
Normally, you will want to start the database server when the computer boots. Autostart scripts are operating-system-specific. There are a few example scripts distributed with PostgreSQL in the contrib/start-scripts directory. Installing one will require root privileges.
Different systems have different conventions for starting up daemons at boot time. Many systems have a file /etc/rc.local or /etc/rc.d/rc.local . Others use init.d or rc.d directories. Whatever you do, the server must be run by the PostgreSQL user account and not by root or any other user. Therefore you probably should form your commands using su postgres -c ‘. ‘ . For example:
su postgres -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog'
Here are a few more operating-system-specific suggestions. (In each case be sure to use the proper installation directory and user name where we show generic values.)
- For FreeBSD , look at the file contrib/start-scripts/freebsd in the PostgreSQL source distribution.
- On OpenBSD , add the following lines to the file /etc/rc.local :
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/postgresql/log -D /usr/local/pgsql/data' echo -n ' postgresql' fi
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
to /etc/rc.d/rc.local or /etc/rc.local or look at the file contrib/start-scripts/linux in the PostgreSQL source distribution. When using systemd , you can use the following service unit file (e.g., at /etc/systemd/system/postgresql.service ):
[Unit] Description=PostgreSQL database server Documentation=man:postgres(1) After=network-online.target Wants=network-online.target [Service] Type=notify User=postgres ExecStart=/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data ExecReload=/bin/kill -HUP $MAINPID KillMode=mixed KillSignal=SIGINT TimeoutSec=infinity [Install] WantedBy=multi-user.target
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
While the server is running, its PID is stored in the file postmaster.pid in the data directory. This is used to prevent multiple server instances from running in the same data directory and can also be used for shutting down the server.
19.3.1. Server Start-up Failures
There are several common reasons the server might fail to start. Check the server’s log file, or start it by hand (without redirecting standard output or standard error) and see what error messages appear. Below we explain some of the most common error messages in more detail.
LOG: could not bind IPv4 address "127.0.0.1": Address already in use HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. FATAL: could not create any TCP/IP sockets
This usually means just what it suggests: you tried to start another server on the same port where one is already running. However, if the kernel error message is not Address already in use or some variant of that, there might be a different problem. For example, trying to start a server on a reserved port number might draw something like:
$ postgres -p 666 LOG: could not bind IPv4 address "127.0.0.1": Permission denied HINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry. FATAL: could not create any TCP/IP sockets FATAL: could not create shared memory segment: Invalid argument DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600).
probably means your kernel’s limit on the size of shared memory is smaller than the work area PostgreSQL is trying to create (4011376640 bytes in this example). This is only likely to happen if you have set shared_memory_type to sysv . In that case, you can try starting the server with a smaller-than-normal number of buffers (shared_buffers), or reconfigure your kernel to increase the allowed shared memory size. You might also see this message when trying to start multiple servers on the same machine, if their total space requested exceeds the kernel limit.
FATAL: could not create semaphores: No space left on device DETAIL: Failed system call was semget(5440126, 17, 03600).
does not mean you’ve run out of disk space. It means your kernel’s limit on the number of System V semaphores is smaller than the number PostgreSQL wants to create. As above, you might be able to work around the problem by starting the server with a reduced number of allowed connections (max_connections), but you’ll eventually want to increase the kernel limit.
Details about configuring System V IPC facilities are given in Section 19.4.1.
19.3.2. Client Connection Problems
Although the error conditions possible on the client side are quite varied and application-dependent, a few of them might be directly related to how the server was started. Conditions other than those shown below should be documented with the respective client application.
psql: error: connection to server at "server.joe.com" (123.123.123.123), port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections?
This is the generic “ I couldn’t find a server to talk to ” failure. It looks like the above when TCP/IP communication is attempted. A common mistake is to forget to configure the server to allow TCP/IP connections.
Alternatively, you might get this when attempting Unix-domain socket communication to a local server:
psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory Is the server running locally and accepting connections on that socket?
If the server is indeed running, check that the client’s idea of the socket path (here /tmp ) agrees with the server’s unix_socket_directories setting.
A connection failure message always shows the server address or socket path name, which is useful in verifying that the client is trying to connect to the right place. If there is in fact no server listening there, the kernel error message will typically be either Connection refused or No such file or directory , as illustrated. (It is important to realize that Connection refused in this context does not mean that the server got your connection request and rejected it. That case will produce a different message, as shown in Section 21.15.) Other error messages such as Connection timed out might indicate more fundamental problems, like lack of network connectivity, or a firewall blocking the connection.
Submit correction
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.
Postgresql server doesn’t start
but if check ps aux there is not such PID (why??) Total reinstalation doesn’t help at all. How can I fix it?
10 Answers 10
This is an idiosyncrasy of the systemd integration of PostgreSQL in Xenial.
The postgresql service unit installed by the postgresql-common package is just a dummy service which causes the actual service postgresql@9.6-main to be started via a dependency. You can see that dependency by running the command
systemctl list-dependencies postgresql That dependency is not permanent, but generated during system boot by the systemd generator /lib/systemd/system-generators/postgresql-generator which also comes with the postgresql-common package. The generator checks whether the startup mode in the file /etc/postgresql/9.6/main/start.conf is set to auto , and if so, sets up the dependency that subsequently causes instance 9.6-main to be started.
(More precisely, it checks all configuration subdirectories /etc/postgresql/*/* and will create dependencies for all instances that are configured for automatic startup, but in a default installation there will be just the one instance.)
Due to the limitations of systemd generators (see man systemd.generator ) this process may fail, causing the dependencies to be absent after a reboot. Systemd will then start only the dummy service, writing
systemd[1]: Starting PostgreSQL RDBMS. systemd[1]: Started PostgreSQL RDBMS. to the log but otherwise doing nothing. Attempting to start the service manually by
systemctl start postgresql will just reproduce that result. Running the command
manually as root will re-run the generator and in most cases fix the problem until the next reboot.
To solve the problem permanently you’ll have to find the reason why the generator fails during boot. Possible causes can be found in the systemd.generator manpage. In my case it was the PostgreSQL config file /etc/postgresql/9.6/main/postgresql.conf which was symlinked to a different filesystem that wasn’t available yet when the generator ran early during boot. postgresql-generator checks the existence of that file even though it doesn’t otherwise need it.