[PostgreSQL] Understanding PostgreSQL Service Status: "Active (Exited)" Explained

Understanding PostgreSQL Service Status: “Active (Exited)” Explained

As a seasoned software engineer, you know that managing services is a crucial aspect of system administration. One common point of confusion for many is interpreting the status of services, especially when dealing with PostgreSQL. A particular case that often raises questions is when postgresql.service shows an “active (exited)” status. This blog post aims to demystify this status and explain why it indicates that PostgreSQL is running normally.

The Service Status Breakdown

Let’s start by examining a typical status output for postgresql.service:

postgresql.service - SYSV: PostgreSQL RDBMS
Loaded: loaded (/etc/rc.d/init.d/postgresql; bad; vendor preset: disabled)
Active: active (exited) since Wed 2024-06-05 11:30:48 CST; 20min ago
Docs: man:systemd-sysv-generator(8)
Process: 20972 ExecStop=/etc/rc.d/init.d/postgresql stop (code=exited, status=0/SUCCESS)
Process: 21648 ExecStart=/etc/rc.d/init.d/postgresql start (code=exited, status=0/SUCCESS)
Tasks: 0
Memory: 0B

Jun 05 11:30:48 xxx systemd[1]: Starting SYSV: PostgreSQL RDBMS...
Jun 05 11:30:48 xxx su[21649]: (to postgres) root on none
Jun 05 11:30:48 xxx postgresql[21648]: Starting PostgreSQL: ok
Jun 05 11:30:48 xxx systemd[1]: Started SYSV: PostgreSQL RDBMS.

At first glance, seeing Active: active (exited) might seem contradictory. If the service is active, why does it show as exited? Let’s break down what this status actually means.

Understanding “Active (Exited)”

1. Service Type:

PostgreSQL is managed as a SysVinit script under systemd. SysVinit scripts traditionally use a “forking” model where the main script starts a process, which then forks a child process to continue running in the background. The parent process exits, indicating to the init system that the service has started successfully.

2. Systemd’s Interpretation:

When systemd manages a SysVinit service, it launches the init script, which in turn starts PostgreSQL. Once the database service is up and running, the init script exits. Systemd marks the service as active (exited) because the script itself has finished executing successfully, and the actual PostgreSQL server process is running in the background.

3. The PostgreSQL Process:

Even though the postgresql.service script has exited, the PostgreSQL daemon (postgres process) continues to run. This can be verified by checking the list of active processes:

ps aux | grep postgres

You should see several PostgreSQL processes running, indicating that the database server is indeed active and handling requests.

Why This is Normal

The active (exited) status is a typical behavior for services managed via SysVinit scripts under systemd. It signifies that:

  • The initial startup script executed successfully.
  • The actual PostgreSQL service (daemon) is running as expected.
  • There are no errors or failures in the startup process.

Memory and Tasks

In the status output, you might notice:

Tasks: 0
Memory: 0B

These lines refer to the systemd service management process itself, not the PostgreSQL daemon. Since the script has exited, it doesn’t consume memory or tasks. However, the PostgreSQL processes will be using resources, which can be monitored separately.

Confirming PostgreSQL is Running

To ensure PostgreSQL is running correctly, you can perform the following checks:

  1. Process Check:

    ps aux | grep postgres

    Look for multiple PostgreSQL processes (e.g., postmaster, worker processes).

  2. Service Logs:

    journalctl -u postgresql.service

    Check for any startup errors or warnings.

  3. Database Connection:

    psql -U yourusername -d yourdatabase

    Attempt to connect to the database to verify it is accepting connections.


The active (exited) status for postgresql.service can be misleading at first glance. However, understanding that this indicates the init script has completed successfully and the PostgreSQL daemon is running in the background clarifies that this is a normal and healthy state. Always remember to cross-verify with running processes and database connections to ensure everything is functioning correctly.

By recognizing this pattern, you can confidently manage and troubleshoot PostgreSQL services, ensuring your database infrastructure remains robust and reliable.