udev와의 싸움

Question 1

systemd-udev 진짜더 이상 규칙에서 직접 파일 시스템을 마운트할 필요가 없습니다. 이 사이트에서 이에 대한 많은 질문을 찾을 수 있습니다 :-).

최신 버전의 systemd에서는 udev 서비스 파일에 SystemCallFilter=@system-service @module @raw-io. 파일 시스템을 마운트하는 데 필요한 시스템 호출이 허용되지 않습니다.

(그리고 만약 당신이한 번mountFUSE 파일 시스템 에 대해 직접 ntfs-3gFUSE 서버 프로세스를 시작하는 경우 이를 전용 시스템 장치(예: unit )에 두는 것이 가장 좋습니다 .mount. 현재 장치 내에 FUSE 프로세스를 유지하는 경우 FUSE 프로세스의 수명 주기는 실행 중인 장치의 수명 주기와 결합됩니다.

RUN+=규칙 의 명령과 관련된 향후(또는 현재) 문제를 방지하려면 대신 다음을 ENV{SYSTEMD_WANTS}=my-automounter@%k.service사용할 수 있습니다.

# /etc/systemd/system/[email protected]
[Service]
Type=oneshot
ExecStart=/usr/local/libexec/my-automounter %I

#!/bin/sh
# /usr/local/libexec/my-automounter

DEV=/dev/"$1"

# You can make this script as complicated as you want.
# You can read udev properties if you want, using 
# eval "$(udevadm info --query=property --export "$DEV")"
...

장치 호출을 수동으로 테스트하려면 를 사용할 수 있습니다 systemctl start my-automounter@sdc1.

systemd가 스크립트를 실행하는 동안 오류가 발생하면 systemctl status my-automounter@*또는 를 사용하여 오류 메시지를 볼 수 있습니다 journalctl -b -u my-automounter@*.

또한 udev특정 오류 보고서를 처리할 필요가 없습니다. 프로그램이 갑자기 멈출 경우를 대비해 두 가지 모두 유용한 오류 보고 기능이 sh있다고 생각합니다 . 예를 들어, :-) 로 차단된 시스템 호출을 호출하려고 했기 때문에 systemd프로그램이 신호에 의해 종료되었는지 보고해야 합니다 .SIGSYSSystemCallFilter=

Answer

systemd-udev 진짜더 이상 규칙에서 직접 파일 시스템을 마운트할 필요가 없습니다. 이 사이트에서 이에 대한 많은 질문을 찾을 수 있습니다 :-).

최신 버전의 systemd에서는 udev 서비스 파일에 SystemCallFilter=@system-service @module @raw-io. 파일 시스템을 마운트하는 데 필요한 시스템 호출이 허용되지 않습니다.