☰

Почему qemu не может запустить сеть только для хоста на обратной петле, если на хосте нет других сетей?

tag-icon • tag-icon networking systemd qemu systemd-service
Почему qemu не может запустить сеть только для хоста на обратной петле, если на хосте нет других сетей?

Начиная qemu-system-x86_64с-nic user,ipv6=off,hostfwd=tcp::9022-:22

Если на хосте присутствует только loинтерфейс (со 127.0.0.1связанным с ним интерфейсом), виртуальная машина запустится, но любой демон, пытающийся выделить порт 22, зависнет. Например, внутри виртуальной машины: #systemctl start sshdпросто зависнет, пока не будет завершен, и в журналах не отобразится ничего интересного.

Если у меня есть любой другой интерфейс на хосте перед запуском qemu, то виртуальная машина также запускается, но порт 22 может быть назначен без проблем. И ssпокажет:

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

Что вызывает эту проблему? Процесс хоста qemu не пытается связать его ни с одним из IP-адресов, зависящих от отсутствующих интерфейсов.

Я не использую kvm. Вот полная команда:

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:127.0.0.1:9023,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;

редактировать: больше внимания уделено systemd

Я думаю, что это исключительно системная проблема. ...вздох.

запуск sshd вручную, используя тот же exec, который должен был использовать systemd, работает просто отлично! sshd по умолчанию слушает 0.0.0.0,

также, это все с использованием стандартных файлов дистрибуции. Ничего пользовательского.

$ cat /lib/systemd/system/sshd.service 
[Unit]
Description=OpenSSH Daemon
#Wants=sshdgenkeys.service
#After=sshdgenkeys.service
#After=network.target

[Service]
ExecStart=/usr/bin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always

[Install]
WantedBy=multi-user.target

(комментарий был о попытке разогнать systemd, но безуспешно)

Кроме того, это находится внутри виртуальной машины с пользовательской сетью, поэтому с точки зрения виртуальной машины сеть всегда действительна:

$ 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 127.0.0.1/8 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 10.0.2.15/24 metric 1024 brd 10.0.2.255 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

и, конечно же, решение было в том, что systemd просто !(*@&#!@ ждал ntp, целую вечность!

как только я выйду в сеть:

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.

Отлично! Нулевая видимость чего-то, что могло бы повлиять на меня навсегда, если бы хост NTP был недоступен или что-то в этом роде... до сих пор не уверен, что связывает эти вещи.

$ systemctl show sshd
...
After=sysinit.target systemd-journald.socket pacman-init.service basic.target system.slice

...я думаю, это потому, что кто-то прикрепил к нему pacman-init.service?! даже если он будет пропущен, так как он запускается только для подписи ключей при первой загрузке?! даже systemctl list-dependencies sshdпокажет все либо полностью зеленым, либо пропущено. никаких предупреждений. Какой позор для опыта.

решение1

Проблема была в том, что systemd меня обманывал. Он ничего не делал, так как ждал зависимости, но не показывал этого ни в одном журнале. И не показывал, что зависимость, которую он ждал, была зависимостью от моей службы.

Переехал вhttps://unix.stackexchange.com/questions/743795/how-to-get-visibility-on-systemd-unit-lifecycle

Связанный контент