Thread: BUG #18671: Unable to Run PostgreSQL on EndeavourOS without Modifying visudo

BUG #18671: Unable to Run PostgreSQL on EndeavourOS without Modifying visudo

From
PG Bug reporting form
Date:
The following bug has been logged on the website:

Bug reference:      18671
Logged by:          rqbin
Email address:      rq_@tutanota.com
PostgreSQL version: 16.3
Operating system:   EndeavourOS (Arch Distro)
Description:

**Watch in a .md editor for better view**

I encountered significant issues when attempting to run PostgreSQL on my
EndeavourOS system. Despite following all standard installation procedures,
I was unable to start PostgreSQL or perform necessary administrative tasks
such as initializing the database. After trying multiple fixes, the only
solution was to modify `visudo` to allow `postgres` to run with
administrative privileges, which should not be necessary.

### **Steps to Reproduce**

1. Installed PostgreSQL via `pacman`:
   ```bash
   sudo pacman -S postgresql
   ```

2. Tried to initialize the PostgreSQL database:
   ```bash
   sudo su - postgres
   initdb --locale=C.UTF-8 --encoding=UTF8 -D '/var/lib/postgres/data'
   ```

3. Encountered permission issues:
   ```bash
   initdb: error: could not access directory "/var/lib/postgres/data":
Permission denied
   ```

4. I attempted the following common solutions:
   - Resetting the `postgres` user password.
   - Ensuring that the `postgres` user had the appropriate privileges and
was part of necessary groups.
   - Starting and enabling the PostgreSQL service via `systemctl`.
   
   None of these steps resolved the issue. I also attempted the recommended
commands such as:
   ```bash
   sudo -u postgres -i
   ```
   But continued to be prompted for a password, which was not accepted
despite resetting it multiple times.

5. The **only** workaround that enabled me to start PostgreSQL successfully
was modifying `visudo` to grant additional privileges to the `postgres`
user.

### **Expected Behavior**

PostgreSQL should run without needing to modify `visudo`. The default
installation and initialization procedures should allow the `postgres` user
to perform administrative tasks without requiring extra steps.

### **System Information**

To provide more insight into my system configuration, here are the specs of
my machine:

Operating System: EndeavourOS (Arch-based)
Kernel Version: 6.6.56-1-lts (64-bit)
Laptop Model: ASUS Vivobook M3401QA
CPU: AMD Ryzen 5 5600H (6 cores, 12 threads, base clock: 2.47 GHz, max
clock: 4.28 GHz)
GPU: AMD Radeon Vega (integrated)
Memory: 8 GB RAM (available: 7.17 GB, used: 6.08 GB)

### **Logs and Outputs**

Here are some relevant logs and error messages from my attempts:

1. **PostgreSQL Service Status:**
   ```bash
   sudo systemctl status postgresql.service
   ```
   Output:
   ```
   × postgresql.service - PostgreSQL database server
     Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled;
preset: disabled)
     Active: failed (Result: exit-code) since [time];
     ...
     /var/lib/postgres/data is missing or empty.
     Failed with result 'exit-code'.
   ```

2. **Permission Denied Error on `initdb`:**
   ```bash
   initdb: error: could not access directory "/var/lib/postgres/data":
Permission denied
   ```

### **Solution Attempted**

I modified `/etc/sudoers` via `visudo` to allow `postgres` to run with more
privileges. This workaround allowed me to start PostgreSQL successfully, but
this is not ideal and should not be the expected behavior.

---

If this issue is specific to EndeavourOS or PostgreSQL on Arch-based
systems, it would be helpful to identify and address the root cause to
improve the experience for future users.


Re: BUG #18671: Unable to Run PostgreSQL on EndeavourOS without Modifying visudo

From
"David G. Johnston"
Date:
On Thu, Oct 24, 2024 at 7:54 AM PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:

Bug reference:      18671
Logged by:          rqbin
Email address:      rq_@tutanota.com
PostgreSQL version: 16.3
Operating system:   EndeavourOS (Arch Distro)
Description:       


1. Installed PostgreSQL via `pacman`:
   ```bash
   sudo pacman -S postgresql
   ```

2. Tried to initialize the PostgreSQL database:
   ```bash
   sudo su - postgres
   initdb --locale=C.UTF-8 --encoding=UTF8 -D '/var/lib/postgres/data'
   ```

It does seem a bit odd that the packager wouldn't initialize an initial cluster; most of them do.  The need to initdb here is surprising.  But, if you do manually run initdb then either the directory you specify for PGDATA must exist OR the parent directory (here, /var/lib/postgres) must exist and the user you are running initdb as must be permitted to create directories in that location.  It is unclear what the case here may be but at the end of the day the OS administrator is responsible for ensuring an appropriate environment exists for initdb to successfully initialize a cluster in the PGDATA (-D) directory.  That likely will require sudo and running mkdir and chown commands.  Then the postgres user can run initdb using the newly created directory owned by them for PGDATA.
 
If this issue is specific to EndeavourOS or PostgreSQL on Arch-based
systems, it would be helpful to identify and address the root cause to
improve the experience for future users.

I suppose they may be looking here but the core project doesn't accept responsibility for the products the various and sundry packagers that exist produce.

In any case I cannot read what you've provided and conclude there is a bug rather than a mis-application of necessary administrative tasks.  I also do not have access to the necessary environment in which to experiment.  Others here may, though again reporting this to the provider of the pacman package directly is more likely to find someone able to experiment and, if there really is a bug, fix things.

For certain, visudo is not the only way to make it so the postgres OS user can run initdb.  But if you want to put things in places only root can write to then involving root will be necessary to establish areas within its domain that postgres can administer, thus precluding the need to empower postgres to operate within the root-restricted areas.

David J.