특정 USB 스틱이 삽입되는 시기를 식별하기 위해 udev 규칙을 사용하고 있습니다. 연결되면 일부 장치를 설치하기 위해 bash 스크립트가 시작됩니다. 설명된 대로 systemd-udev 서비스를 일부 변경한 후 훌륭하게 작동했습니다.여기.
그러나 설치 중 하나가 실패했습니다. 퓨즈 병합 마운트입니다. 명령 자체는 성공한 것 같지만 ls설치 폴더에서 작업을 수행할 때 이상한 출력이 나타나고 폴더에 액세스할 수 없습니다.
d????????? ? ? ? ? ? mountpoint
하지만 터미널에서 mount 명령을 수동으로 실행하면 모든 것이 정상입니다.
부팅하는 동안 스틱을 삽입하든 시스템 부팅 후에 삽입하든 상관없습니다. mountfusion-mergerfs 장치 마운트는 udev 스크립트에서 호출할 때 아무런 효과가 없습니다 .
어떤 생각이 있나요?
답변1
[udev 규칙에서 RUN 사용]은 시간 초과 후에도 계속 실행 중인 경우 종료되므로 수명이 짧은 스크립트에만 작동합니다.
즉, 파일 시스템을 구현하는 FUSE 백그라운드 프로세스가 종료됩니다.
대안을 생각했습니다. 명령이 있으면 systemd-mount명령 대신 이를 사용해 볼 수 있습니다 mount. 임시 .mount셀( .service셀이 아님) 을 만들고 mount해당 셀 내에서 프로그램을 실행합니다.
내가 인용한 소스는 장기 실행 프로세스에 대한 보다 일반적인 솔루션을 제공하려고 시도합니다.
https://yakking.branchable.com/posts/systemd-2-udevd/
더 오래 실행되는 서비스가 필요한 경우 다음과 같이 단위를 정의하여 시스템 단위와 통합해야 합니다.
cat >/etc/systemd/system/[email protected] <<'EOF' [Unit] Description=My Service [Service] Type=simple ExecStart=/path/to/your/script %I EOF
ENV{SYSTEMD_WANTS}="my-service@%k.service"udev 규칙에 추가되었습니다 .그러면 /path/to/your/script가 실행되고 방금 나타난 장치의 경로가 전달됩니다.
안타깝게도 위의 설명은 귀하의 경우에는 적용되지 않습니다.
문제는 스크립트 자체가 반환되기까지 너무 오래 걸리는 것이 아닙니다. 문제는 FUSE 파일 시스템을 구현하는 프로세스인 "백그라운드 프로세스"를 시작한 후 스크립트가 반환된다는 것입니다. 스크립트가 완료되면 systemd스크립트에 의해 시작된 나머지 프로세스를 정리하고 종료해야 한다고 간주합니다.
이 상황은 이전 sysvinit 스크립트와 매우 유사합니다. 따라서 우리는 그들과 동일한 솔루션을 사용할 수 있습니다.
mountFUSE 파일 시스템 에 systemd 서비스를 쓸 때 Type=simple또는 를 사용하지 마십시오 Type=oneshot. 대신 사용하십시오 Type=forking.