"/usr/lib/udev/hwclock-set"에 파일이 있습니다:
RTC에서 올바른 날짜/시간을 설정해야 하지만 문제가 있습니다.
if [ -e /run/systemd/system ] ; then
exit 0
fi
/shin/hwclock ....
이제 udev가 hwclock 규칙을 실행하면 위 폴더가 이미 존재하므로 시스템 시간을 설정하지 않고 스크립트가 종료됩니다.
이 조건 뒤에 숨은 아이디어는 무엇입니까?
또한 udev 규칙 및 systemd 서비스가 이 스크립트를 통해 시스템 시간을 설정하는 것을 방지합니다.
나를 미치게 해. 이 장애물을 처리할 수 있는 udev 규칙이나 시스템 서비스는 없습니다.
추가 2: "exit"의 주석 처리를 제거하고 udev 규칙이 이 스크립트를 실행하려고 하면 모든 "hwclock" 호출이 1(오류)을 반환합니다.
이 스크립트를 수동으로 실행하면(주석 처리되지 않은 "exit" 사용) 시간이 올바르게 설정됩니다.
답변1
현대적인 systemd-udevd
운영
CapabilityBoundingSet=~CAP_SYS_TIME CAP_WAKE_ALARM
서비스 파일에. 이는 udev 규칙에 의해 시작된 프로세스를 의미합니다.시스템 시간을 조작할 수 없습니다., 함수가 하위 프로세스 CAP_SYS_TIME
에서 제외되었기 때문입니다.udevd
반면에 systemd
부팅 프로세스 초기(기본적으로 부팅 시) systemd
의 (첫 번째) RTC에서 시스템 시계 설정을 자체적으로 처리 해야 합니다. 이를 성공적으로 달성하려면 하드웨어 RTC 드라이버를 모듈이 아닌 커널에 내장해야 합니다.
또는 하드웨어에 여러 RTC가 있는 경우 시스템 시간에 원하는 RTC 드라이버가 내장되어야 하며 다른 드라이버는 로드 가능한 모듈이어야 합니다. 이를 통해 올바른 RTC가 감지되도록 해야 하며 , 이는 분명히 시스템 시간을 설정하는 rtc0
데 자동으로 사용되는 RTC입니다 .systemd
systemd
분명히, 이 동작은 하드웨어에 여러 개의 RTC가 있고 사용하려는 RTC가 아래와 같이 커널에서 첫 번째 RTC로 감지되지 않는 경우 약간의 놀라움을 초래할 수 있습니다.최근에 귀하가 주신 또 다른 질문.
물론 여러 RTC가 있는 임베디드 시스템을 다루고 RTC 드라이버를 모듈로 요구하는 경우 udev
파일에서 해당 줄을 제거하고 차단 조건을 제거하여 하위 프로세스가 시스템 시간을 조작하도록 허용하는 것이 효과적일 수 있습니다. 파일에서. 문서.CapabilityBoundingSet=
systemd-udevd.service
/usr/lib/udev/hwclock-set
새로운 "표준 설정"의 가장 큰 장점은 다음과 같습니다.모든 로그에는 올바른 타임스탬프가 있어야 합니다.일단 systemd
시작하면 생각할 필요도 없습니다. 적절한 RTC 드라이버 모듈을 로드한 후 udev 규칙이 시스템 시계 설정을 처리하도록 변경하면 초기 부팅 시 잘못된 타임스탬프가 있는 일부 메시지가 기록될 수 있으므로 로그를 읽을 때 이 점을 염두에 두어야 합니다.