Why qemu fails to start host only network on loopback when there's no other network on host?

sd flag

Starting qemu-system-x86_64 with -nic user,ipv6=off,hostfwd=tcp::9022-:22

With only the lo interface (with associated to it) present on the host, the vm will start, but any daemon trying to allocate port 22 will hang. e.g. inside vm: #systemctl start sshd will just hang until killed, and nothing interesting will show up on logs.

If I have any other interface up on the host before starting qemu, then the vm also starts, but port 22 can be assigned just fine. And ss will show:

Netid   State  Recv-Q Send-Q  Local Address:Port  Peer Address:Port  Process
tcp     LISTEN 0      1*          users:(("qemu-system-x86",pid=9035,fd=12))

What is causing this issue? The qemu host process is not trying to associate it with any of the IPs that depends on the missing interfaces.

I am not using kvm. here's the full command:

qemu-system-x86_64 -machine pc,vmport=off,mem-merge=off,dump-guest-core=off,kernel-irqchip=split -smp 4 -m 1G,slots=4,maxmem=8G -name vm -monitor tcp:,server,nowait -msg timestamp=on,guest-name=on -rtc base=utc,clock=host,driftfix=none -pidfile .vm_started -daemonize -no-reboot -D .vm.log -nic user,id=n1,ipv6=off,hostname=vm,hostfwd=tcp::9022-:22,hostfwd=tcp::8000-:8000 -boot c -drive file=linux-x86.qcow2,index=0,media=disk,snapshot=off,format=qcow2;

edit: More focus on systemd

I think this is exclusively a systemd issue. ...sigh.

starting sshd manually, using the exact same exec systemd should have been using, works just fine! sshd defaults to listen,

also, this is all using standard distribution files. Nothing custom.

$ cat /lib/systemd/system/sshd.service 
Description=OpenSSH Daemon

ExecStart=/usr/bin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID


(commented stuff was to try to unclock systemd, no luck)

also, this is inside a vm with user network, so it always have a valid network from the vm point of view:

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    altname ens3
    inet metric 1024 brd scope global dynamic eth0
       valid_lft 84976sec preferred_lft 84976sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

and of course, the solution was that systemd was just !(*@&#!@ waiting for ntp, for forever!

as soon as i get online:

Apr 23 15:58:16 archlinux systemd[1]: Reached target System Time Synchronized.
Apr 23 15:58:16 archlinux systemd[1]: Started Refresh existing PGP keys of archlinux-keyring regularly.
Apr 23 15:58:16 archlinux systemd[1]: Started Daily verification of password and group files.
Apr 23 15:58:16 archlinux systemd[1]: Reached target Timer Units.
Apr 23 15:58:16 archlinux systemd[1]: Initializes Pacman keyring was skipped because of an unmet condition check (ConditionFirstBoot=yes).
Apr 23 15:58:16 archlinux systemd[1]: Started OpenSSH Daemon.

Nice! zero visibility on something that would impact me forever in case that ntp host wasn't reachable or something... still unsure what is tying those things.

$ systemctl show sshd
... systemd-journald.socket pacman-init.service system.slice

...i guess it is because someone attached pacman-init.service to it?! even though it will be skipped as it only run to sign the keys at first boot?! even systemctl list-dependencies sshd would show everything either all green or skipped. no warnings. What a disgrace of experience.

sd flag

Issue was that systemd was gaslighting me. It was doing nothing as it was waiting for a dependency, but it was not showing that in any log. Nor it was showing that the dependency it was waiting for was a dependency on my service.

Moved to


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.