Quadlet network dependencies need to identify the right network{-online}.target unit

[DevDorrejo]

Feature request description

On openSUSE (and some other distros), network-online.target often remains inactive unless a wait-online service is explicitly enabled, while network.target is reliably reached. Quadlet’s helper (podman-user-wait-network-online.service) waits for network-online.target and times out. Quadlet should detect and wait for the correct target (online or basic) depending on the system, or allow selecting it without hacks.

Steps to reproduce

On openSUSE, run a user-scoped Quadlet unit that waits for the network (e.g., via --user).

Observe podman-user-wait-network-online.service timing out because network-online.target never becomes active.

Actual behavior

podman-user-wait-network-online.service polls network-online.target, but that target is inactive (dead). The service times out and dependent pods/units don’t start in time.

Expected behavior

Quadlet should:

Automatically detect whether to wait for network-online.target or network.target and proceed when the appropriate one is active; or

Expose an explicit option to choose the target (e.g., RequireNetwork=auto|online|basic) with auto as default and a fallback to network.target when network-online.target doesn’t progress.

Environment

Distro: openSUSE

Scope: user (systemd --user)

Networking: the system reaches network.target, but does not activate network-online.target by default.

Tools:~ # systemctl status network.target
● network.target - Network
Loaded: loaded (/usr/lib/systemd/system/network.target; static)
Active: active since Tue 2025-10-14 15:08:45 AST; 18h ago

Tools:~ # systemctl status network-online.target
○ network-online.target - Network is Online
Loaded: loaded (/usr/lib/systemd/system/network-online.target; static)
Active: inactive (dead)

Suggest potential solution

Proposed change:

Automatic mode with fallback: Adjust the Quadlet wait helper to proceed when either of these conditions are met:

network-online.target becomes active; or

If network-online.target remains inactive for N seconds, check network.target and proceed if it’s active.

Suggested shell logic (pseudocode based on current ExecStart):

/bin/sh -c '
  deadline=$(( $(date +%s) + ${QUADLET_NET_WAIT:-30} ))
  while [ "$(date +%s)" -lt "$deadline" ]; do
    systemctl is-active --quiet network-online.target && exit 0
    sleep 0.5
  done
  systemctl is-active --quiet network.target && exit 0
  while ! systemctl is-active --quiet network.target; do sleep 0.5; done

[ygalblum]

I'm not sure giving up and falling back to a different target is the right way. Maybe wait on a different service based on the target O/S.
I looked at the install.systemd Makefile rule and I think this can be implement with a variable, (maybe BUILDTAGS).

@Luap99 WDYT? Do these variables get populated during RPM installation or at the RPM build time?

[Luap99]

This isn't distro specific so build time options will not really be useful. In any case it is just a normal systemd service that anyone could overwrite via drop in to their liking already so I don't see a strong benifit in this.

I would say this is a duplicate of #24796, honestly I am not sure what to do. I am not really willing to make this work around more involved/complicated than it already is. Really the root cause is us being unable to depend on system level targets in user units.

Overall I like to remove this work around with 6.0 maybe, pasta has a local mode now so it should start up fine most likely though there are still some weird problem around early startup, i.e. #25656, so a full netlink monitor solution in pasta would likely need to be added first.