클라이언트가 다시 시작될 때 usbip이 제대로 다시 시작되지 않습니다(Docker 컨테이너에서).

클라이언트가 다시 시작될 때 usbip이 제대로 다시 시작되지 않습니다(Docker 컨테이너에서).

짧은 버전: Hyper-V VM에서 ubuntu 18.04.02를 usbip 클라이언트로 실행하고, ubuntu 18.04를 Raspberry Pi에서 usb 서버로 실행합니다. Hyper-V VM은 Docker 컨테이너에서 Home Assistant(예: hass.io)를 실행합니다. Hyper-V 가상 머신이 다시 시작되면 rPi의 usbip 서비스가 다시 시작될 때까지 usbip 서비스가 rPi의 서버 측에 다시 연결할 수 없는 경우가 있습니다.

이는 Hyper-V VM이 (--권한이 있는) 도커 컨테이너 내부에서 다시 시작될 때만 발생하는 것으로 보입니다. 우분투 셸에서 다시 시작하면 작동합니다.

두 클라이언트 모두 linux-tools-generic(이전 독립 실행형 패키지 아님)의 usbip를 사용하며 버전 2로 식별됩니다. 저는 두 가지를 하나의 서비스로 패키지했습니다. 서버 측은 유형 포크로 실행되고 클라이언트 측은 일회성으로 실행됩니다. 둘 다 새로 시작하면 제대로 작동합니다.

다음은 연결할 수 없는(디버깅이 활성화된) 클라이언트(Hyper-V) 다시 시작에 대한 로깅입니다. 길이에 대해 사과드립니다. 꽤 많이 잘렸지만 남은 내용이 관련성이 있는지 잘 모르겠습니다.

모든 것이 정상이면 클라이언트에서 전송된 것이며 연결된 원격 포트를 볼 수 있습니다.

root@ha:~# usbip port
Imported USB devices
====================
Port 00: <Port in Use> at Full Speed(12Mbps)
       Cygnal Integrated Products, Inc. : unknown product (10c4:8a2a)
       1-1 -> usbip://192.168.132.100:3240/1-1.2
           -> remote bus/dev 001/004

Hyper-V(usbip 클라이언트) 측에서 docker를 다시 시작하면 종료할 때의 로그는 다음과 같습니다.

May  2 13:07:04 ha NetworkManager[1181]: <info>  [1556802424.0981] device changed (path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:00/VMBUS:00/f8091f75-727b-47ed-85fd-ce642aa4be61/net/eth0, iface: eth0)
May  2 13:07:04 ha ModemManager[964]: <info>  (tty/ttyUSB1): released by modem /sys/devices/platform/vhci_hcd.0/usb1/1-1
May  2 13:07:04 ha ModemManager[964]: <warn>  [plugin manager] task 0,ttyUSB1: error when checking support with plugin 'Iridium': 'Operation was cancelled'
May  2 13:07:04 ha ModemManager[964]: <warn>  [plugin manager] task 0,ttyUSB1: failed: Operation was cancelled
May  2 13:07:04 ha NetworkManager[1181]: <info>  [1556802424.1522] device changed (path: /sys/devices/virtual/net/docker0, iface: docker0)

이는 서버(rPi usbip 서버) 측의 동일한 종료 메시지입니다. rPi가 종료되지 않는다는 점에 유의하세요. 이것은 단지 Hyper-V 종료에 대한 응답일 뿐입니다(또는 더 정확하게는 이것이 일상적이고 종료되는 것 같습니다). Hyper-V 종료에 응답 하트비트가 아닌 이상 실제 응답은 없지만 어쨌든 주기적으로 나타납니다.

May  2 13:06:56 ubuntu kernel: [41155.172199] usbip-host 1-1.2: endpoint 0 is stalled
May  2 13:06:56 ubuntu kernel: [41155.176078] usbip-host 1-1.2: endpoint 0 is stalled
May  2 13:07:03 ubuntu usbipd: usbipd: debug: usbipd.c:573:[do_standalone_mode] heartbeat timeout on ppoll()

Hyper-V는 재부팅 후 이 상태로 돌아갑니다.

May  2 13:11:27 ha kernel: [    2.810394] systemd[1]: Set hostname to <ha>.
May  2 13:11:27 ha kernel: [    2.977418] systemd[1]: /lib/systemd/system/usbip.service:9: Ignoring unknown escape sequences: "/usr/lib/linux-tools/$(uname -r)/usbip detach --port=$(/usr/lib/linux-tools/$(uname -r)/usbip port | grep '<Port in Use>' | sed -E 's/^Port ([0-9][0-9]).*/\1/')"

참고: 위의 줄은 서비스 정의의 ExecStop 섹션에서 가져온 것입니다. 서비스가 시작되기 전에 시작 시 어떻게 실행되는지는 확실하지 않지만 아무 작업도 수행하지 않는 것 같습니다. (현재로서는) 찾아서 분리할 포트가 없기 때문에 이 오류가 발생하는 것 같습니다.

May  2 13:11:28 ha sh[1380]: usbip: error: recv op_common
May  2 13:11:28 ha sh[1380]: usbip: error: query
May  2 13:11:28 ha systemd[1]: Starting Docker Application Container Engine...
May  2 13:11:28 ha systemd[1]: usbip.service: Main process exited, code=exited, status=1/FAILURE
May  2 13:11:28 ha systemd[1]: usbip.service: Failed with result 'exit-code'.
May  2 13:11:28 ha systemd[1]: Failed to start usbip client.
May  2 13:11:28 ha systemd[1]: Started Permit User Sessions.

이 오류로 인해 서비스가 시작되지 않으며 수동으로 시작되지 않습니다(아래 동일한 오류). 이 시점에서 클라이언트는 원격 장치를 볼 수 있지만 연결할 수는 없습니다(이 매뉴얼 예제 참조).

root@ha:~# usbip list -r zwave
Exportable USB devices
======================
 - zwave
      1-1.2: Cygnal Integrated Products, Inc. : unknown product (10c4:8a2a)
           : /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2
           : (Defined at Interface level) (00/00/00)
           :  0 - Vendor Specific Class / unknown subclass / unknown protocol (ff/00/00)
           :  1 - Vendor Specific Class / unknown subclass / unknown protocol (ff/00/00)

root@ha:~# usbip port
Imported USB devices
====================
root@ha:~# usbip attach -r zwave -b 1-1.2
usbip: error: recv op_common
usbip: error: query

하지만 서버(rPi)에서 연결을 시도하면 위 명령에 대한 응답은 다음과 같습니다. 클라이언트는 먼저 버스 ID를 가져오기 위해 목록을 수행한 다음 추가를 수행하므로 목록이 연결되고 추가가 실패하는 것을 볼 수 있습니다.

May  2 13:11:28 ubuntu usbipd: usbipd: debug: usbipd.c:568:[do_standalone_mode] read event on fd[0]=4
May  2 13:11:28 ubuntu usbipd: usbipd: info: connection from 192.168.132.254:34686
May  2 13:11:28 ubuntu usbipd: usbipd: info: received request: 0x8005(6)
May  2 13:11:28 ubuntu usbipd: usbipd: info: exportable devices: 1
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:91:[dump_usb_device] path                 = /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:92:[dump_usb_device] busid                = 1-1.2
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:98:[dump_usb_device] Device(C/SC/P)       = (Defined at Interface level) (00/00/00)
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:100:[dump_usb_device] bcdDevice            = 100
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:105:[dump_usb_device] Vendor/Product       = unknown vendor : unknown product (10c4:8a2a)
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:107:[dump_usb_device] bNumConfigurations   = 1
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:108:[dump_usb_device] bNumInterfaces       = 2
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:111:[dump_usb_device] speed                = Full Speed(12Mbps)
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:113:[dump_usb_device] busnum               = 1
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:114:[dump_usb_device] devnum               = 4
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:84:[dump_usb_interface] Interface(C/SC/P)    = unknown class / unknown subclass / unknown protocol (ff/00/00)
May  2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:84:[dump_usb_interface] Interface(C/SC/P)    = unknown class / unknown subclass / unknown protocol (ff/00/00)
May  2 13:11:28 ubuntu usbipd: usbipd: info: request 0x8005(6): complete
May  2 13:11:28 ubuntu usbipd: usbipd: debug: usbipd.c:568:[do_standalone_mode] read event on fd[0]=4
May  2 13:11:28 ubuntu usbipd: usbipd: info: connection from 192.168.132.254:34688
May  2 13:11:28 ubuntu usbipd: usbipd: info: received request: 0x8003(6)
May  2 13:11:28 ubuntu usbipd: usbipd: info: found requested device: 1-1.2
May  2 13:11:28 ubuntu usbipd: usbip: debug: usbip_host_common.c:233:[usbip_export_device] device not available: 1-1.2
May  2 13:11:28 ubuntu usbipd: usbip: debug: usbip_host_common.c:239:[usbip_export_device] status SDEV_ST_USED
May  2 13:11:28 ubuntu usbipd: usbipd: debug: usbipd.c:152:[recv_request_import] import request busid 1-1.2: failed
May  2 13:11:28 ubuntu usbipd: usbipd: info: request 0x8003(6): failed

위의 이상한 점은 장치가 있다고 말하는 것 같지만 사용할 수 없으며 마치 사용 중이고 어떻게든 예약된 것처럼(이전에 출시되지 않은 것처럼?) 상태가 SDEV_ST_USED라고 표시된다는 것입니다.

그런 다음 때로는 (추론에 따르면 우분투를 다시 시작하는 docker가 아니라 우분투 셸이 언제 다시 시작되는지 확실하지 않음) 제대로 작동합니다.

rPi 서비스는 계속 실행되므로 서비스가 실패하는 것이 아니라 연결이 실패하는 것이 자동으로 다시 시작되지 않습니다. 먼저 rPi 서버를 수동으로 다시 시작한 다음 HyperV VM 클라이언트를 다시 시작하여 제대로 작동하도록 하세요. 서비스 정의에서 클라이언트를 자동으로 다시 시작할 수 있지만 문제를 해결하려면 rPi usbip 서비스를 다시 시작해야 하므로 소용이 없습니다.

예, 짧은 대답은 항상 도커 컨테이너가 아닌 우분투에서 재부팅하는 것을 기억하는 것입니다.

하지만... 더 강력한 대답이 있을까요? 서버 측 정리가 제대로 수행되지 못하게 할 수 있는 일부 구성 또는 설정 문제가 있습니까?

이론적으로는 서버를 원격으로 다시 시작하고 준비가 될 때까지 기다리는 클라이언트 다시 시작 스크립트를 작성할 수 있을 것 같지만 이는 매우 취약해 보입니다.

어떤 통찰력이 있습니까?

추신. 반대 시나리오도 문제라는 점에 유의해야 합니다. rPi에서 usbip 서비스를 다시 시작하면 클라이언트(Hyper-V VM)는 서비스가 아직 연결되어 있다고 생각하지만 작동하지 않으며 다시 시작해야 합니다. rPi 서버를 다시 시작할 필요가 거의 없고 홈어시스턴트 소프트웨어를 개발 중이고 자주 다시 시작되므로 이는 큰 문제가 아닙니다. 그러나 근본적인 문제는 비슷합니다. 한쪽 끝을 다시 시작하면 다른 쪽 끝이 손상될 수 있습니다.

관련 정보