Обсуждение: PostgreSQL 15 on Fedora 37 Does not start after reboot
PostgreSQL 15 on Fedora 37 Does not start after reboot
The service is enabled and reports a network error after reboot. Starting the postgresql service manually after the reboot is successful.
From the log file:
2023-01-01 09:22:26.406 EST [812] LOG: starting PostgreSQL 15.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2), 64-bit
2023-01-01 09:22:26.406 EST [812] LOG: could not bind IPv4 address "192.168.122.124": Cannot assign requested address
2023-01-01 09:22:26.406 EST [812] WARNING: could not create listen socket for "192.168.122.124"
2023-01-01 09:22:26.406 EST [812] FATAL: could not create any TCP/IP sockets
2023-01-01 09:22:26.417 EST [812] LOG: database system is shut down
Suggested fix:
Edit /usr/lib/systemd/system/postgresql-15.service and change the
After=network.target line to
After=network-online.target
Tom Dryden <tdryden@comcast.net> writes:
> PostgreSQL 15 on Fedora 37 Does not start after reboot
> The service is enabled and reports a network error after reboot.
> Starting the postgresql service manually after the reboot is successful.
> From the log file:
> 2023-01-01 09:22:26.406 EST [812] LOG: starting PostgreSQL 15.1 on
> x86_64-pc-linux-gnu, compiled by gcc (GCC) 12.2.1 20220819 (Red Hat
> 12.2.1-2), 64-bit
> 2023-01-01 09:22:26.406 EST [812] LOG: could not bind IPv4 address
> "192.168.122.124": Cannot assign requested address
This indicates that Postgres is starting before the network
interface is up, something that systemd is prone to try to do.
> Suggested fix:
> Edit /usr/lib/systemd/system/postgresql-15.service and change the
> After=network.target line to
> After=network-online.target
Right, although some authorities suggest also adding
Wants=network-online.target
In any case, that service file is not created or distributed by us.
I suggest filing this as a bug against the Fedora postgresql package.
regards, tom lane
Fedora Bugzila report ID 2157651 has been submitted.
Thanks
Tom
Tom Dryden <tdryden@comcast.net> writes:
PostgreSQL 15 on Fedora 37 Does not start after reboot
The service is enabled and reports a network error after reboot.
Starting the postgresql service manually after the reboot is successful.
From the log file:
2023-01-01 09:22:26.406 EST [812] LOG: starting PostgreSQL 15.1 on
x86_64-pc-linux-gnu, compiled by gcc (GCC) 12.2.1 20220819 (Red Hat
12.2.1-2), 64-bit
2023-01-01 09:22:26.406 EST [812] LOG: could not bind IPv4 address
"192.168.122.124": Cannot assign requested address
This indicates that Postgres is starting before the network
interface is up, something that systemd is prone to try to do.
Suggested fix:
Edit /usr/lib/systemd/system/postgresql-15.service and change the
After=network.target line to
After=network-online.target
Right, although some authorities suggest also adding
Wants=network-online.target
In any case, that service file is not created or distributed by us.
I suggest filing this as a bug against the Fedora postgresql package.
regards, tom lane
Hi, On Sun, 2023-01-01 at 18:14 -0500, Tom Lane wrote: > Right, although some authorities suggest also adding > Wants=network-online.target > > In any case, that service file is not created or distributed by us. > I suggest filing this as a bug against the Fedora postgresql package. This is PGDG RPMs (based on the unit file name). Pushed a fix: https://git.postgresql.org/gitweb/?p=pgrpms.git;a=commit;h=b0d12f55ba4e0301137e51f7cda1f6ceb1448cd6 I'm inclined to hold this until next month's updates, as there is already a workaround. Regards, -- Devrim Gündüz Open Source Solution Architect, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= <devrim@gunduz.org> writes:
> On Sun, 2023-01-01 at 18:14 -0500, Tom Lane wrote:
>> I suggest filing this as a bug against the Fedora postgresql package.
> This is PGDG RPMs (based on the unit file name). Pushed a fix:
Ah, thanks.
> I'm inclined to hold this until next month's updates, as there is
> already a workaround.
Agreed. I think this is not a problem if listen_addresses is "*"
or "localhost", so it probably doesn't affect all that many people.
regards, tom lane