.png)
시스템 단위 파일, 특히 장치 단위 파일을 추적하는 방법은 무엇입니까? 저는 리눅스 커널 버전 3.18을 사용하고 있습니다. 내 보드에서는 systemd가 시작된 후 (mypartition).device가 실행되고 rootfs를 다시 마운트하려고 합니다. systemd-analyze 다이어그램에 표시된 것처럼 완료하는 데 약 2초가 걸립니다. rootfs를 다시 마운트하는 데는 많은 시간(보통 몇 밀리초)이 걸리지 않기 때문에 그 2초 안에 무엇을 하는지 알고 싶습니다. 유닛 파일이 너무 많은 systemd-analyze 다이어그램을 어떻게 이해합니까? 어떤 유닛이 다른 유닛을 실행하게 하는지 알 수 있습니까? 내 시스템에서 .device 단위 파일을 찾아보았지만 아무 것도 찾을 수 없습니다.
답변1
커널 버전 3.18은 2014년 12월에 출시되었기 때문에 꽤 오래된 버전입니다. 이는 장기적으로 지원되는 커널 중 하나이며, 이 커널 버전은 2017년 1월에 "공식적인" 수명이 종료되지만 여전히 Greg Kroah-Hartman으로부터 가끔 업데이트를 받을 수 있습니다. 따라서 이 커널 버전은 특히 임베디드 시스템에서 다른 운영 체제 구성 요소의 수명을 나타내는 신뢰할 수 있는 지표가 될 필요는 없습니다.
시스템에서 무엇을 보고합니까 systemctl --version?
최신 버전의 systemd에서는 파일 시스템 마운트가 단위로 처리됩니다 *.mount. 특히, 루트 파일 시스템의 마운트 단위의 내용을 보려면 강제로 해석이 (옵션 대신) 단위 이름이 되도록 -.mount해야 합니다 . 이 명령을 사용하면 루트 파일 시스템을 포함하는 장치를 나타내는 장치/대상에 따라 마운트 장치가 자동으로 정렬되는 것을 볼 수 있습니다 .systemctl cat -- -.mount-.mountAfter=
이러한 *.device장치는 커널에 의해 감지되고 /sys가상 파일 시스템 및 udev유지 관리 장치 노드(해당되는 경우 장치 노드 없이 처리되는 네트워크 장치 등)에서 해당 표현을 가져오는 장치로 나타납니다.
이러한 단위는 일반적으로 자동으로 생성되므로 일반적으로 어디서도 단위 파일을 찾을 *.device수 없습니다 . *.device반대로 udev 규칙은 장치 단위 생성에 영향을 미칠 수 있습니다. 예를 들어 udev 규칙이 SYSTEMD_READY=0장치의 속성을 설정하는 경우 해당 속성이 제거되거나 변경될 때까지 장치 생성이 무시됩니다 SYSTEMD_READY=1. man systemd.device자세한 내용은 참조하십시오 .
기본적으로 이러한 *.device단위는 하드웨어 장치를 나타내기 위해 존재하며 주로 다른 단위가 해당 종속성을 정의할 수 있도록 합니다. 기본적으로 장치 단위는 다른 장치에 의존하지 않고 정의에 따라 해당 장치가 나타내는 사용자 공간 액세스 가능 장치에 "의존"합니다.
표시되는 2초는 다음 작업의 조합으로 인해 발생할 수 있습니다.
- 디스크 컨트롤러가 포함된 버스를 감지하고 준비합니다(시스템 아키텍처에 해당하는 경우).
- 디스크 컨트롤러 자체 감지 및 재설정
- Linux 커널 드라이버가 디스크 제어권을 인수하면 시스템 펌웨어가 수행한 작업 후에 디스크를 알려진 상태로 가져오기 위해 디스크를 감지하고 재설정합니다(이 작업은 2초 정도 걸릴 수 있음). 재설정 시 실행되는 광범위한 내부 자체 테스트 루틴이 있을 수 있음)
- 디스크의 파티션 테이블을 읽고 식별하고 처리합니다(Linux 커널은 여러 파티션 테이블 형식을 지원합니다. 하드웨어 아키텍처에 따라 둘 이상이 적합할 수 있음).