파일 시스템의 서로 다른 위치에 여러 하위 볼륨이 마운트된 btrfs 설정이 있습니다. 각 하위 볼륨에는 스내퍼 구성이 있습니다.
고양이/etc/conf.d/snapper
[...]
SNAPPER_CONFIGS="root home [...]"
시작 시 스냅샷을 생성하는 서비스는 파일에 정의되어 있습니다.
고양이/usr/lib/systemd/system/snapper-boot.service
[...]
ExecStart=/usr/bin/snapper --config root --cleanup-algorithm number --description "boot"
ExecStart=/usr/bin/snapper --config home --cleanup-algorithm number --description "boot"
[...]
하위 볼륨당 하나의 행을 추가하는 대신, 잘못되기 쉬운 것 같아요스내퍼 구성 목록을 읽고 반복합니다..
가능합니까?
바람직합니까?
답변1
예, 가능합니다.
간단한 방법은 snapper
각 구성에 대해 한 번씩 반복적으로 호출되는 쉘 스크립트를 사용하는 것입니다. for
이 작업을 수행하려면 루프만으로 충분할 것 같습니다 .
시스템 단위 파일에서 이 작업을 인라인으로 수행할 수도 있습니다.
ExecStart=/bin/sh -e -c '. /etc/conf.d/snapper; for conf in $$SNAPPER_CONFIGS; do /usr/bin/snapper --config "$$conf" --cleanup-algorithm number --description "boot"; done'
$
systemd가 이를 systemd 변수로 해석하지 않고 대신 쉘이 이를 해석할 수 있도록 s를 이스케이프해야 합니다 . (제 생각에는 호출하는 외부 쉘 스크립트를 사용하는 것이 ExecStart=
더 깔끔한 접근 방식이므로 이스케이프 처리를 처리하고 모든 것을 한 줄에 넣을 필요가 없습니다.)
또 다른 옵션은 snapper
문제를 기본적으로 처리할 수 있도록 자체를 수정하는 것입니다. 예를 들어 해당 구성 파일을 읽고 인수 없이 호출될 때 구성을 처리하도록 합니다 --config
. 이것이 더 깔끔한 접근 방식이 될 것입니다.
추천이냐 아니냐...에 따라 다를 것 같아요. 배포판 패키지에서 이 장치를 얻으면 snapper-boot.sevice
이 파일과 관련된 패키지 업그레이드가 있을 때마다 문제가 발생할 수 있습니다. 따라서 어느 정도는 특정 상황에 따라 다릅니다.
이 유닛 파일이 Linux 배포판 패키지와 함께 제공되는 경우 버그 보고서를 열어서 유닛 파일에 구성 이름을 하드코딩하지 않도록 요청하는 것이 좋습니다.
배포판에 속하지 않는 경우 일반적으로 Linux 배포판에서 제공하고 관리하는 파일용으로 예약되어 있으므로 /etc/systemd/system
해당 배포판에 저장하는 것이 좋습니다./usr/lib