Posted on by richay

Docker Commands Taking 1–2 Minutes to Respond

Status: CURRENT — ENVIRONMENT-SPECIFIC FIX
Last reviewed: 31 August 2026
Applies to: Debian-based Proxmox LXC containers running Docker where systemd-networkd-wait-online is enabled even though networking is actually handled by ifupdown

My Docker commands were taking roughly two minutes to respond after the LXC started. Docker itself wasn’t slow. A redundant systemd-networkd-wait-online.service was sitting there for about two minutes waiting for a network state that was never going to arrive, while Docker waited behind network-online.target.

This one annoyed me because Docker looked guilty as hell.

I would run:

docker ps


and… nothing.

No error. No useful message. Just a blinking cursor for a good minute or two.

Then suddenly the command would return and basically every container showed:

Up Less than a second


Which was the first clue that Docker hadn’t been sitting there slowly thinking about the answer. Docker had only just been allowed to bloody start.

It also seemed to be affecting Plex

This LXC also runs my Plex server.

Before I fixed the network wait, refreshing app.plex.tv would load my Plex account quickly enough, but my own server/library could take another 10–15 seconds to actually appear.

After fixing this Docker/network startup mess, the library population became basically instant.

I can’t prove the extra Plex delay was caused by exactly the same systemd wait-online mechanism. What I can say is that both problems disappeared when I cleaned up the networking on this LXC. So I would treat slow Plex server discovery as another clue that the host/container networking is worth looking at rather than immediately blaming Plex itself.

It also appeared to clear up some of the weird Plex indirect/relay behaviour I’d been seeing around the same time. Again: observed before/after, not a peer-reviewed scientific paper about my Plex box 😀

First: prove Docker is actually the thing that’s slow

Check Docker:

systemctl status docker --no-pager -l
systemctl status containerd --no-pager -l


Then look at boot timing:

systemd-analyze blame | head -30
systemd-analyze critical-chain docker.service


My result was hilariously obvious:

2min 149ms systemd-networkd-wait-online.service
    1.052s docker.service
    1.011s ifupdown-wait-online.service


Docker itself took about one second.

The two-minute corpse lying across the road was systemd-networkd-wait-online.service.

The critical chain made it even clearer

systemd-analyze critical-chain docker.service


Mine showed:

docker.service +1.052s
└─network-online.target @2min 384ms
  └─ifupdown-wait-online.service @123ms +1.011s


So the Docker daemon wasn’t taking two minutes to initialise. It was ordered behind network-online.target, and that target wasn’t being considered ready until the networking wait mess had finished.

systemd’s own documentation describes network-online.target as an active synchronisation point that can deliberately delay services until networking is considered online. The matching wait-online service is supposed to come from the network manager you’re actually using.

Key phrase there:

the network manager you're actually using


I had two wait-online systems in the same LXC

This command exposed the stupid bit:

systemctl list-units --all | grep -E 'wait-online|network-online'


My LXC had:

ifupdown-wait-online.service
    active / exited

systemd-networkd-wait-online.service
    failed / failed

network-online.target
    active


And:

systemctl --failed


showed systemd-networkd-wait-online.service sitting there failed.

This Debian LXC was using the traditional ifupdown networking from /etc/network/interfaces. It already had ifupdown-wait-online.service, which completed in about one second.

Meanwhile systemd-networkd-wait-online was also enabled and waiting for systemd-networkd’s idea of an online network.

It never got happy, so it eventually hit its timeout.

The current systemd manual says the default systemd-networkd-wait-online timeout is 120 seconds.

Oh look. There’s our two bloody minutes.

Check which network manager is actually configuring the LXC

Do not blindly disable systemd-networkd on every Linux machine because this article fixed my LXC. If your machine genuinely uses systemd-networkd, then its wait-online service may be completely legitimate and you need to fix the networkd configuration instead.

Check the classic Debian config first:

cat /etc/network/interfaces
ls -la /etc/network/interfaces.d/


Then check the services:

systemctl is-active networking
systemctl is-enabled ifupdown-wait-online.service
systemctl is-enabled systemd-networkd.service
systemctl is-enabled systemd-networkd-wait-online.service


And if you think systemd-networkd is genuinely in use:

networkctl list
networkctl status
ls -la /etc/systemd/network/


In my case, ifupdown was doing the actual networking job. The extra networkd wait-online service was just standing in the doorway refusing to let Docker through.

The fix in my LXC

Because this container was using ifupdown rather than systemd-networkd for its network configuration, I disabled the redundant wait-online service:

systemctl disable --now systemd-networkd-wait-online.service


If it has previously been force-enabled by something and keeps coming back, you can inspect its enablement first:

systemctl is-enabled systemd-networkd-wait-online.service
systemctl cat systemd-networkd-wait-online.service


I would only mask it if I had confirmed the LXC does not need it and something kept trying to start it:

systemctl mask systemd-networkd-wait-online.service


Masking is stronger than disabling, so don’t throw it around just because it sounds more decisive.

Should I disable systemd-networkd itself?

Not automatically.

The broken bit I actually found was the wait-online service. If your LXC is definitely configured entirely through ifupdown and systemd-networkd has no job at all, then removing the redundant network manager may also make sense:

systemctl disable --now systemd-networkd.service


But only do that after checking /etc/systemd/network, networkctl and your actual interface configuration.

Turning off the network manager that really owns your IP address is an impressively efficient way to turn a remote server into a trip across the house.

Reboot and test it properly

I rebooted the LXC because that was the scenario where the delay actually mattered:

reboot


Then immediately checked:

time docker ps
systemd-analyze blame | head -20
systemctl --failed


Instead of staring at a blinking cursor for two minutes, docker ps was basically instant.

And unlike before, the containers weren’t all reporting that they’d come alive one second ago because Docker had been held hostage for the first two minutes of the boot.

Why docker ps looked like it was hanging

My boot logs showed docker.socket becoming available very early, while docker.service was still waiting further down the boot chain.

Docker can be socket-activated by systemd. So from the user’s point of view:

run docker ps
    ↓
Docker client connects to /run/docker.sock
    ↓
systemd wants docker.service
    ↓
docker.service is waiting behind network-online.target
    ↓
systemd-networkd-wait-online sits there
    ↓
120 second timeout
    ↓
dockerd starts in ~1 second
    ↓
all containers start
    ↓
docker ps finally returns


Which is why this felt like a Docker command problem even though the real delay was happening one layer underneath it.

The Docker logs were actually pretty clean

Once Docker was allowed to start, the daemon did exactly what it was supposed to do:

Loading containers: done.
Daemon has completed initialization
API listen on /run/docker.sock


That was another useful clue.

If dockerd starts in a second and its logs show normal container restoration, don’t spend the next hour rebuilding Docker networks because a completely different systemd service stole 120 seconds before Docker even got a turn.

Ignore unrelated LXC noise until it proves it’s relevant

The logs also had some very scary-looking container-specific rubbish such as:

mount: /sys/kernel/config: permission denied
modprobe: FATAL: Module overlay not found in directory /lib/modules/...


Those messages are worth understanding, but they weren’t the thing consuming two minutes in my timing output.

This is why systemd-analyze blame was so useful. It stopped me chasing every red-looking log line and pointed directly at the bastard actually eating the time.

If you really do use systemd-networkd

Don’t disable its wait service just to make the number disappear.

The current systemd-networkd-wait-online tool can be told to:

  • Wait for a particular interface with --interface=.
  • Ignore interfaces with --ignore=.
  • Succeed when any suitable interface is online with --any.
  • Use a different timeout with --timeout=.
  • Ignore a link for online decisions using RequiredForOnline=no in its .network config.

If networkd genuinely owns the network, fix why it thinks an interface isn’t online. Don’t just remove the smoke alarm because it’s noisy.

My Plex result was the nice bonus

The Docker fix was obvious: two-minute CLI hang became instant.

The nicer surprise was Plex.

BEFORE

refresh app.plex.tv
      ↓
account loads
      ↓
wait...
      ↓
10–15 seconds
      ↓
my own library finally appears


AFTER

refresh app.plex.tv
      ↓
boom — library is there


I wouldn’t use that as proof that systemd-networkd-wait-online directly causes slow Plex discovery on every system.

But if Docker startup is stuck behind broken network readiness and Plex is acting weird with server discovery, relay/indirect connections or slow library population, I’d absolutely investigate the underlying Linux network state before pulling Plex apart.

Quick diagnosis version

# What is actually slow?
systemd-analyze blame | head -30

# What is Docker waiting for?
systemd-analyze critical-chain docker.service

# Do I have multiple wait-online systems?
systemctl list-units --all | grep -E 'wait-online|network-online'

# What has actually failed?
systemctl --failed

# Which networking system am I using?
cat /etc/network/interfaces
networkctl list


If you see:

ifupdown-wait-online.service            active
systemd-networkd-wait-online.service      failed
systemd-networkd-wait-online              ~120 seconds


and you’ve confirmed ifupdown is the real network manager, you’ve probably found the same stupid little problem I did.

Final result

Docker was not slow.

Docker:
  ~1 second

Wrong wait-online service:
  ~2 minutes

Plex library:
  10–15 seconds → instant

Time spent blaming Docker:
  more than Docker deserved


This is one of those fixes I love because nothing needed more CPU, more RAM, a Docker reinstall or some heroic network rebuild.

One stale/redundant service was sitting in the boot path waiting two minutes for something the LXC wasn’t even using.

Removed the pointless wait and suddenly Docker stopped looking drunk, Plex woke up properly, and the whole box felt normal again.

Linux: where the problem is never the thing you’re currently swearing at 😀

References

Leave a Reply

Your email address will not be published. Required fields are marked *