---
id: 12d7d39c-b08b-45bb-b231-cc08cfd0274b
---

# Password Authentication Failure for Postgres User
---

This incident type occurs when there is a failure in the authentication process for the Postgres user's password. This can happen due to a variety of reasons such as incorrect login credentials, expired passwords, or database configuration issues. It is important to address this type of incident promptly to ensure that the database remains secure and accessible only to authorized users.

### Parameters
```shell
export PATH_TO_POSTGRES_LOG_FILE="PLACEHOLDER"

export POSTGRES_USER="PLACEHOLDER"

export NEW_PASSWORD="PLACEHOLDER"

export PATH_TO_DATABASE_CONFIGURATION_FILE="PLACEHOLDER"
```

## Debug

### Next Step
```shell
shell

# Step 1: Check if Postgres service is running

systemctl status postgresql.service
```

### Step 2: Verify if Postgres user exists
```shell
sudo su - postgres -c "psql -c \"SELECT 1\""
```

### Step 3: Check if the password for Postgres user is correct
```shell
sudo su - postgres -c "psql -c \"\du\""
```

### Step 4: Check if password expiration for Postgres user is enabled
```shell
sudo su - postgres -c "psql -c \"SHOW password_encryption\""
```

### Step 5: Check if there are any relevant logs for the authentication failure
```shell
grep -i "authentication failed" ${PATH_TO_POSTGRES_LOG_FILE}
```

### Step 6: Check if there are any relevant logs for the database connection failure
```shell
grep -i "could not connect" ${PATH_TO_POSTGRES_LOG_FILE}
```

### The database configuration settings have been changed or misconfigured, leading to authentication issues.
```shell


#!/bin/bash



# Define the database configuration file path

DB_CONFIG_FILE=${PATH_TO_DATABASE_CONFIGURATION_FILE}



# Check if the database configuration file exists

if [ -f "$DB_CONFIG_FILE" ]; then



  # Check the configuration settings for the Postgres user

  grep "postgres" $DB_CONFIG_FILE | grep "password"



  # Check if the authentication method is set to "password"

  grep "postgres" $DB_CONFIG_FILE | grep "auth-method"



else

  echo "Database configuration file does not exist."

fi


```

## Repair

### Verify that the user is entering the correct login credentials. If the user is unsure of their login credentials, reset their password and provide them with the new login information.
```shell


#!/bin/bash



# Set variables

POSTGRES_USER=${POSTGRES_USER}

NEW_PASSWORD=${NEW_PASSWORD}



# Verify correct login credentials

if psql -U "$POSTGRES_USER" -c "SELECT 1" > /dev/null 2>&1; then

    echo "User $POSTGRES_USER has authenticated successfully"

else

    # Reset password

    psql -U postgres -c "ALTER USER $POSTGRES_USER PASSWORD '$NEW_PASSWORD';"

    echo "Password for user $POSTGRES_USER has been reset to $NEW_PASSWORD"

fi


```


This incident type occurs when there is a failure in the authentication process for the Postgres user's password. This can happen due to a variety of reasons such as incorrect login credentials, expired passwords, or database configuration issues. It is important to address this type of incident promptly to ensure that the database remains secure and accessible only to authorized users.


This incident type usually occurs when there is a failure in the SSL Handshake process between a client and server running on a Tomcat web server. This can happen for various reasons such as incorrect SSL certificate configuration, cipher suite mismatches, or network connectivity issues. When this type of incident is not resolved quickly, it can lead to downtime or service disruptions for users trying to access the affected service.


Tomcat SSL Handshake Failure Incident

This incident type refers to a situation where the Tomcat server's JDBC connection pool usage surpasses its configured limits. This can lead to a shortage of available connections for incoming requests, resulting in slow response times or even server crashes. It is important to monitor and manage the JDBC connection pool usage to prevent such incidents from occurring.


Tomcat High JDBC Connection Pool Usage Incident.

This incident type occurs when there are too many locks acquired on a Postgresql database instance. This can cause issues with database performance and functionality. It may be necessary to adjust the max\_locks\_per\_transaction setting in Postgresql to prevent this issue from occurring.


Postgresql too many locks acquired

This incident type refers to a situation where the Postgresql database has a high rollback rate, which means that a high percentage of transactions are being aborted compared to the committed ones. This can cause issues with data consistency and performance, and may require investigation and resolution by the responsible team. The incident details may include information about the affected database instance, the service or system impacted, the urgency level, and any related alerts or escalations.


Postgresql high rollback rate incident

This incident type refers to a scenario where there is a high rate of statement timeouts in a Postgresql database instance. This can lead to degraded performance and potentially impact the availability of the database. It is important to quickly identify and address the underlying cause of the timeouts to ensure the stability of the system.


Postgresql high rate statement timeout incident.

```shell
export PATH_TO_POSTGRES_LOG_FILE="PLACEHOLDER"

export POSTGRES_USER="PLACEHOLDER"

export NEW_PASSWORD="PLACEHOLDER"

export PATH_TO_DATABASE_CONFIGURATION_FILE="PLACEHOLDER"
```


### Next Step

```shell
shell

# Step 1: Check if Postgres service is running

systemctl status postgresql.service
```

### Step 2: Verify if Postgres user exists

```shell
sudo su - postgres -c "psql -c \"SELECT 1\""
```

### Step 3: Check if the password for Postgres user is correct

```shell
sudo su - postgres -c "psql -c \"\du\""
```

### Step 4: Check if password expiration for Postgres user is enabled

```shell
sudo su - postgres -c "psql -c \"SHOW password_encryption\""
```

### Step 5: Check if there are any relevant logs for the authentication failure

```shell
grep -i "authentication failed" ${PATH_TO_POSTGRES_LOG_FILE}
```

### Step 6: Check if there are any relevant logs for the database connection failure

```shell
grep -i "could not connect" ${PATH_TO_POSTGRES_LOG_FILE}
```

### The database configuration settings have been changed or misconfigured, leading to authentication issues.

```shell


#!/bin/bash



# Define the database configuration file path

DB_CONFIG_FILE=${PATH_TO_DATABASE_CONFIGURATION_FILE}



# Check if the database configuration file exists

if [ -f "$DB_CONFIG_FILE" ]; then



  # Check the configuration settings for the Postgres user

  grep "postgres" $DB_CONFIG_FILE | grep "password"



  # Check if the authentication method is set to "password"

  grep "postgres" $DB_CONFIG_FILE | grep "auth-method"



else

  echo "Database configuration file does not exist."

fi


```


### Verify that the user is entering the correct login credentials. If the user is unsure of their login credentials, reset their password and provide them with the new login information.

```shell


#!/bin/bash



# Set variables

POSTGRES_USER=${POSTGRES_USER}

NEW_PASSWORD=${NEW_PASSWORD}



# Verify correct login credentials

if psql -U "$POSTGRES_USER" -c "SELECT 1" > /dev/null 2>&1; then

    echo "User $POSTGRES_USER has authenticated successfully"

else

    # Reset password

    psql -U postgres -c "ALTER USER $POSTGRES_USER PASSWORD '$NEW_PASSWORD';"

    echo "Password for user $POSTGRES_USER has been reset to $NEW_PASSWORD"

fi


```


Password Authentication Failure for Postgres User

Overview

Parameters

Debug

Next Step

Step 2: Verify if Postgres user exists

Step 3: Check if the password for Postgres user is correct

Step 4: Check if password expiration for Postgres user is enabled

Step 5: Check if there are any relevant logs for the authentication failure

Step 6: Check if there are any relevant logs for the database connection failure

The database configuration settings have been changed or misconfigured, leading to authentication issues.

Repair

Learn more

Related Runbooks

Tomcat SSL Handshake Failure Incident

Tomcat High JDBC Connection Pool Usage Incident.

Postgresql too many locks acquired

Postgresql high rollback rate incident

Support