Bug#1099664: postgresql-common: Should use network-online.target instead of network.target in systemd service

[Christoph Anton Mitterer]

Hey.

I've stumbled over this bug when I thought to suffer from the same
issue, but mine turned out to rather be what I describe in #1122511.

Still systemd.special(7) describes network.target as:
>This unit is supposed to indicate when network functionality is 
> available, but it is only very weakly defined what that is supposed to mean. 
> However, the following should apply
>at minimum:
> 
>•   At start-up, any configured synthetic network devices (i.e. 
> not physical ones that require hardware to show up and be probed, but virtual 
> ones like bridge devices and similar
>which are created programmatically) that do not depend on any 
> underlying hardware should be allocated by the time this target is reached. 
> It is not necessary for these
>interfaces to also have completed IP level configuration by 
> the time network.target is reached.

in particular, no guarantees that physical devices are already there
and configured.

Cheers,
Chris.

Bug#1099664: postgresql-common: Should use network-online.target instead of network.target in systemd service

[Christoph Berg]

Control: tags -1 moreinfo

Re: Aurélien Pardon
> $ cat /var/log/postgresql/postgresql-14-main.log
> [...]
> 2025-03-06 01:41:03.982 CET [1990] LOG:  could not bind IPv4 address 
> "172.25.2.13": Cannot assign requested address

Hi,

thanks for bringing this up.

I'm not sure changing this would really fix the problem. If wifi is
down, this would either still break, or delay starting the database
indefinitely.

Do you really need to bind to that IP directly? The standard setup
would be `listen_address = '*'`, then startup doesn't need any
specific IP to be available.

There is also the `net.ipv4.ip_nonlocal_bind` sysctl know that you
could enable.

Christoph

Bug#1099664: postgresql-common: Should use network-online.target instead of network.target in systemd service

[Aurélien Pardon]

Package: postgresql-common
Version: 267.pgdg22.04+1
Severity: normal
X-Debbugs-Cc: aurelien.pardon+deb...@gmail.com

Dear Maintainer,


The systemd service file for PostgreSQL currently uses "network.target", since 
a fixed wishlist https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910991. 
However, this does not guarantee that the network is fully available, which can 
lead to startup failures.

Suggested fix:
The service should instead use "network-online.target" to ensure that the 
network is fully up before PostgreSQL starts.

Besides, that is what postgresql proposes in its documentation:
https://www.postgresql.org/docs/current/server-start.html
```
[Unit]
Description=PostgreSQL database server
Documentation=man:postgres(1)
After=network-online.target
Wants=network-online.target
```

Here is the Systemd documentation
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/#conceptsinsystemd
about the targets:
> - network.target has very little meaning during start-up. It only indicates 
> that the network management stack is up after it has been reached. [...]
> - network-online.target is a target that actively waits until the nework is 
> "up", where the definition of "up" is defined by the network management 
> software. [...]


Steps to reproduce:
1. Install PostgreSQL on a system with a slow DHCP or Wi-Fi connection.
2. Reboot and observe that PostgreSQL may fail to start due to missing network 
resources.


Here is a timeline of what happened recently on my server:
```
$ cat systemctl status network.target
[...]
Mar 06 01:41:00 prod3 systemd[1]: Reached target Network.

$ cat /var/log/postgresql/postgresql-14-main.log
[...]
2025-03-06 01:41:03.982 CET [1990] LOG:  could not bind IPv4 address 
"172.25.2.13": Cannot assign requested address
2025-03-06 01:41:03.982 CET [1990] WARNING:  could not create listen socket for 
"172.25.2.13"

$ sudo systemctl status network-online.target
[...]
Mar 06 01:41:11 prod3 systemd[1]: Reached target Network is Online.
```

As you can see, the interface was available only after
network-online.target, so postgresql failed to bind on it before. 
It happened on an 18.04 ubuntu server, on a 14 cluster, but I think the
issue is still relevant today. 
> Package: postgresql-common
> Version: 250.pgdg18.04+1



Thanks for considering this issue (my first one! please excuse any
mistakes).