Score:1

Ubuntu 22.04 Desktop: on restart, some services do not bind to public IP, only localhost

sd flag

I have a fresh install of Ubuntu 22.04 Desktop on which I want to run public services (postgreSQL, redis, etc.) to access from other hosts. I configured each service to bind (listen) to the static IP 192.168.1.xxx as well as localhost, started them, and they work.

When I restart the computer, these services are not listening on 192.168.1.xxx, only on localhost/127.0.0.1. When I restart the service, it binds to all addresses. No changes. No Firewall. SSH does connect via the IP address. Here is a paste of the Redis example run locally immediately after a reboot.

% sudo ufw status                                                                                                 
Status: inactive

% redis-cli -h 192.168.1.200
Could not connect to Redis at 192.168.1.200:6379: Connection refused
not connected>

% redis-cli -h 127.0.0.1
127.0.0.1:6379>

% redis-cli -h localhost
localhost:6379>

% sudo lsof -i :6379
COMMAND    PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
redis-ser 3004 redis    6u  IPv4  35436      0t0  TCP localhost:redis (LISTEN)
redis-ser 3004 redis    7u  IPv6  35437      0t0  TCP ip6-localhost:redis (LISTEN)

% sudo service redis-server restart

% sudo lsof -i :6379
COMMAND     PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
redis-ser 14396 redis    6u  IPv4  67757      0t0  TCP localhost:redis (LISTEN)
redis-ser 14396 redis    7u  IPv6  67758      0t0  TCP ip6-localhost:redis (LISTEN)
redis-ser 14396 redis    8u  IPv4  67759      0t0  TCP server:redis (LISTEN)

% redis-cli -h 192.168.1.200
192.168.1.200:6379>

What would be preventing the services from binding to public IP addresses during boot? Anthing to do with it being a desktop install? Thank you in advance for you time!

waltinator avatar
it flag
Watch your system start up, discover its hardware, and _start the services_ with the terminal command `sudo journalctl -b 0`.
Score:0
sd flag

Thanks everyone who posted suggestions. It supported my hunch that the network was not yet ready when the service started. I was able to confirm:

  • A super-clean install of Ubuntu 22.04 Desktop VM had the same issue (services did not bind to public IP on restart, only loopback addresses).
  • A clean install of Ubuntu 22.04 Server worked as expected (services started listening to the given IP addresses).
  • It seems the start-up differs for Server and Desktop. Perhaps the network is configured after/within the GUI Desktop?
  • This link about systemd has more in depth information: https://unix.stackexchange.com/questions/126009/cause-a-script-to-execute-after-networking-has-started#126146
  • The above link spoke of binding with a wildcard address (* or 0.0.0.0) instead of the literal public static IP. This works! It may not be what you want if you have multiple network interfaces though...but then you likely won't use Desktop in that case.
  • A complete solution would involve learning systemd and debugging start-up.
Score:0
iq flag

The service might start before the network interface is fully ready and configured that make the service only bind with localhost instead of the IP you want.

You can do these things to check if it is fully ready and configured before the service start, first configure your systemd service file to be dependant on the network being up by adding this line to the [Unit] section After=network-online.target. You can also modify /etc/systemd/resolved.conf to include your static IP address, for example

DNS=192.168.1.1
Domains=example.com

You can also use the traditional network configuration method, edit /etc/NetworkManager/NetworkManager.conf and set managed=false then, configure your network interface in the /etc/network/interfaces file. Also in the systemd service file you could delay the start of the service with this:

ExecStartPre=/bin/sleep 30
ExecStart=/usr/bin/postgresql
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.