BUG #16565: Systemd service file does not create /var/run/postgresql directory across reboot

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

BUG #16565: Systemd service file does not create /var/run/postgresql directory across reboot

apt.postgresql.org Repository Update
The following bug has been logged on the website:

Bug reference:      16565
Logged by:          Marco Cuccato
Email address:      [hidden email]
PostgreSQL version: 12.3
Operating system:   Red Hat Enterprise Linux Server release 7.6
Description:        

When the server is rebooted, PostgreSQL service doesn't start because of
this error:
FATAL:  could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock":
No such file or directory

This happens because it tries to create the lock file under
/var/run/postgresql that doesn't exists. It doesn't exist because /var/run
is a symlink to ../run (/run as absolute path) that is mounted as tmpfs.
As tmpfs is not persistent, when the server is rebooted the directory
doesn't exists and must be re-created.
Doing that, the lock file will be created successfully and the service will
start up correctly.

Please fix the postgresql-12.service systemd file: make it check and
eventually create /var/run/postgresql directory.
Thanks

Reply | Threaded
Open this post in threaded view
|

Re: BUG #16565: Systemd service file does not create /var/run/postgresql directory across reboot

Marco Cuccato
Fixed by myself creating a /etc/systemd/system/postgresql-12.service with this content:

.include /usr/lib/systemd/system/postgresql-12.service
[Service]
RuntimeDirectory=postgresql

The  RuntimeDirectory directive should be included in original /usr/lib/systemd/system/postgresql-12.service file.

Il giorno ven 31 lug 2020 alle ore 15:01 PG Bug reporting form <[hidden email]> ha scritto:
The following bug has been logged on the website:

Bug reference:      16565
Logged by:          Marco Cuccato
Email address:      [hidden email]
PostgreSQL version: 12.3
Operating system:   Red Hat Enterprise Linux Server release 7.6
Description:       

When the server is rebooted, PostgreSQL service doesn't start because of
this error:
FATAL:  could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock":
No such file or directory

This happens because it tries to create the lock file under
/var/run/postgresql that doesn't exists. It doesn't exist because /var/run
is a symlink to ../run (/run as absolute path) that is mounted as tmpfs.
As tmpfs is not persistent, when the server is rebooted the directory
doesn't exists and must be re-created.
Doing that, the lock file will be created successfully and the service will
start up correctly.

Please fix the postgresql-12.service systemd file: make it check and
eventually create /var/run/postgresql directory.
Thanks

Reply | Threaded
Open this post in threaded view
|

Re: BUG #16565: Systemd service file does not create /var/run/postgresql directory across reboot

Devrim GÜNDÜZ
In reply to this post by apt.postgresql.org Repository Update
Hi,

We already create that directory:

https://git.postgresql.org/gitweb/?p=pgrpms.git;a=blob;f=rpm/redhat/master/non-common/postgresql-12/master/postgresql-12-tmpfiles.d;h=6c48e34ed1c10c66a651b98acadacb326fb3bacd;hb=HEAD

Are you using community RPMs, or RHEL ones?

Regards, Devrim


On 31 July 2020 13:05:14 GMT+03:00, PG Bug reporting form <[hidden email]> wrote:
The following bug has been logged on the website:

Bug reference: 16565
Logged by: Marco Cuccato
Email address: [hidden email]
PostgreSQL version: 12.3
Operating system: Red Hat Enterprise Linux Server release 7.6
Description:

When the server is rebooted, PostgreSQL service doesn't start because of
this error:
FATAL: could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock":
No such file or directory

This happens because it tries to create the lock file under
/var/run/postgresql that doesn't exists. It doesn't exist because /var/run
is a symlink to ../run (/run as absolute path) that is mounted as tmpfs.
As tmpfs is not persistent, when the server is rebooted the directory
doesn't exists and must be re-created.
Doing that, the lock file will be created successfully and the service will
start up correctly.

Please fix the postgresql-12.service systemd file: make it check and
eventually create /var/run/postgresql directory.
Thanks


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply | Threaded
Open this post in threaded view
|

Re: BUG #16565: Systemd service file does not create /var/run/postgresql directory across reboot

Marco Cuccato
Sorry for delay.


Il giorno ven 31 lug 2020 alle ore 22:03 Devrim Gündüz <[hidden email]> ha scritto:
Hi,

We already create that directory:

https://git.postgresql.org/gitweb/?p=pgrpms.git;a=blob;f=rpm/redhat/master/non-common/postgresql-12/master/postgresql-12-tmpfiles.d;h=6c48e34ed1c10c66a651b98acadacb326fb3bacd;hb=HEAD

Are you using community RPMs, or RHEL ones?

Regards, Devrim


On 31 July 2020 13:05:14 GMT+03:00, PG Bug reporting form <[hidden email]> wrote:
The following bug has been logged on the website:

Bug reference: 16565
Logged by: Marco Cuccato
Email address: [hidden email]
PostgreSQL version: 12.3
Operating system: Red Hat Enterprise Linux Server release 7.6
Description:

When the server is rebooted, PostgreSQL service doesn't start because of
this error:
FATAL: could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock":
No such file or directory

This happens because it tries to create the lock file under
/var/run/postgresql that doesn't exists. It doesn't exist because /var/run
is a symlink to ../run (/run as absolute path) that is mounted as tmpfs.
As tmpfs is not persistent, when the server is rebooted the directory
doesn't exists and must be re-created.
Doing that, the lock file will be created successfully and the service will
start up correctly.

Please fix the postgresql-12.service systemd file: make it check and
eventually create /var/run/postgresql directory.
Thanks


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.