☰

설치 장치 대신 서비스 장치 사용

tag-icon • tag-icon mount systemd
설치 장치 대신 서비스 장치 사용

Systemd 설치 장치와 systemctl 호출을 사용하여 다음 명령 시퀀스를 표현하고 싶습니다.

# mount /some/path /some/mountpoint -o ro
# mount /some/mountpoint -o remount,rw
# touch /some/mountpoint/foo # placeholder for write action
# mount /some/mountpoint -o remount,ro

개념적 문제는 systemd.mount(5)가 마운트 지점에서 실행된다는 점인 것 같습니다. 셀은 전체 경로를 systemctl에 전달하여 활성화되므로 동일한 마운트 지점에 여러 개의 셀을 설치할 수 없습니다. 템플릿은 장착 장치에도 적합하지 않습니다.

그럼 어떻게 작동하나요? 가능합니까?

답변1

설치 장치 대신 서비스 장치 사용

mount 명령을 사용하는 간단한 일회용 서비스 장치는 나의 재마운트 사용 사례에 적합합니다(귀하의 사용 사례에도 효과가 있을 것으로 생각합니다).

일반적으로 마운트가 이미 정의되어 /etc/fstab있고 fstab 항목이 systemd에 의해 자동으로 생성된다는 점을 고려하면 <mountpoint>.mount두 가지 접근 방식이 있습니다.

  1. 설치 단위 대신 표준 서비스 단위로 돌아가서 설치 명령을 직접 제어하면 됩니다.
  2. systemd 재정의를 사용해 보시겠습니까? (테스트되지 않았으며 실행 가능한 것으로 간주되지 않음)
    • 장치를 마운트하는 데는 엄격한 요구 사항이 있습니다. 즉, 마운트 지점을 기준으로 장치 이름을 지정하는 것입니다. 따라서 동일한 마운트 지점에 대해 두 개의 별도 마운트 장치를 실행하는 것이 불가능할 수도 있습니다(질문에 언급되어 있음).
    • 따라서 fstab에서 생성된 원래 마운트 장치 정의를 덮어쓰고 두 번 수행하지 않는다고 가정하면 다시 마운트할 때 작동하지 않을 수 있습니다.
    • 시도할 경우 아직 설치되지 않은 항목에 다시 설치 옵션이 적용되므로 원래 설치가 실패할 가능성이 높습니다.

예

유사한 것이 필요했고 systemd를 사용하여 유닛 유형을 설치하려고 할 때 다음 문제에 부딪혔습니다(마운트 지점을 기반으로 유닛 파일 이름을 정의하지 않았기 때문입니다):

Where= setting doesn't match unit name. Refusing.

더 많은 공간이 있는 데이터 디렉토리에 바인드 마운트를 수행했지만 상위 마운트 지점에 nosuid 및 nodev가 설정되어 있는 경우 /var/lib/lxc에 lxc에 대한 suid 및 dev 권한을 추가해야 합니다.

서비스 단위 파일 /etc/systemd/system/lxc-remount.service:

[Unit]
Description=Remount the /var/lib/lxc folder with suid and dev privileges
Requires=var-lib-lxc.mount
After=var-lib-lxc.mount
Before=lxc.service

[Service]
Type=oneshot
ExecStart=/bin/mount -o remount,rw,suid,dev,relatime,discard,data=ordered /var/lib/lxc

[Install]
WantedBy=lxc.service

이를 효과적으로 수행하는 명령:

$ sudo systemctl daemon-reload
$ sudo systemctl enable lxc-remount.service
Created symlink from /etc/systemd/system/lxc.service.wants/lxc-remount.service to /etc/systemd/system/lxc-remount.service.
$ sudo systemctl start lxc-remount.service

답변2

이것은기술적으로systemd이 기능은 장착 장치 상단에 구현할 수 있습니다. 그래서 단순히 "아니요"라고 대답할 수는 없습니다. 이 접근 방식에는 몇 가지 단점이 있습니다.

반면, 명령을 사용하여 재설치 부분을 수행하면 "systemd를 사용하여 장치 설치"를 제외한 모든 요구 사항을 충족할 수 있습니다 mount. 사람들은 일반적 으로 systemd이 명령을 사용하는 것을 좋아 합니다 mount. 예를 들어 임시 마운트 해제 파일 시스템을 사용하는 경우 umount시스템 마운트 장치는 로 표시됩니다 inactive. mount파일 시스템을 수동으로 마운트하면 systemd는 이에 대한 임시 마운트 단위를 생성합니다. (유닛을 생성하지 않습니다.문서).

그래서실제로mount재설치 작업을 수행하려면 이 명령을 사용하는 것이 좋습니다 .

이 질문을 읽고 있는데 이 mount명령을 사용하지 말아야 할 또 다른 이유가 있는 경우 새로운 질문을 하고 그 이유를 지정하십시오. 그러한 이유를 알지 못하면 실제로 다음 방법을 사용하지 않는 것이 좋습니다. 이는 교육 목적으로만 사용됩니다.

Options=장착 단위 설정을 변경한 후 systemctl reload장착 단위를 변경 해야 합니다 .

에 포함된 파일을 사용하여 이 작업을 수행할 수 있으므로 /run/systemd/system/디스크 구성을 편집할 필요가 없습니다. 시스템이 중간에 충돌하더라도 오래된 구성이 남을 위험은 없습니다.

그러나 그다지 "깨끗한" 것은 아닙니다. 여전히 위험이 있습니다.주문하다도중에 중단되고 오래된 구성이 남아 있을 수 있습니다.둘place - 커널의 마운트 상태와 systemd의 마운트 상태입니다. 그럼에도 불구하고 그것을 사용할 때 첫 번째 문제는 남아 있습니다 mount. 하지만 이는 첫 번째 문제를 해결하고 두 번째 문제는 잊어버릴 수 있음을 의미합니다. 그러면 두 번째 질문은 나중에 많은 혼란을 야기할 수 있습니다.

참고로, 삽입 파일을 생성하거나 유닛 파일을 편집할 때, 설치 유닛을 다시 로드하기 전에 새로운 값을 얻기 위해 실행도 해야 합니다 systemctl daemon-reload.Option=

두 번째 문제는 다음과 같습니다. 적어도 아직은 사용을 권장하지 않습니다. systemctl daemon-reload약간 무거운 작업입니다 :-). 운이 좋지 않으면 원치 않는 부작용이 발생할 수도 있습니다. 어떤 시점에서는 개별 단위 파일을 다시 로드하기 위해 일부 코드가 추가되었지만 사용 가능한 기능으로 문서화된 것을 본 적이 없습니다.

(또한 특수 유닛 디렉토리 중 하나가 /run/systemd/system.control/"dbus API를 사용하여 생성된 임시 구성"으로 설명되어 있음을 확인했습니다. 이는 리소스 제어 설정 및 일부 기타 설정의 변경 사항을 추적하는 데 사용된다고 생각합니다. 이는 특별한 경우이며 변경 사항을 사용하여 만들어졌습니다 systemctl --runtime set-property. 전체 다시 로드가 필요하지 않습니다.

답변3

왜 스크립트를 사용하지 않습니까? 편집할 수 있도록 시스템 일시 중지를 어떻게 설정합니까?

내 생각엔 다음과 같은 스크립트가 당신에게 아주 좋을 것 같아요.

#!/bin/bash
mount /some/mountpoint -o remount,rw
bash
# do some editing
# touch /some/mountpoint/foo # placeholder for write action
exit the shell/ctrl-d
mount /some/mountpoint -o remount,ro

관련 정보