서비스를 제거하고 싶지 않고 부팅 시 시작되는 것을 피하고 싶습니다. 나중에 수동으로 시작하려면( command 사용 systemctl start <service>) 옵션이 필요합니다.
.it을 사용해 보았습니다 systemctl disable <service>. 서비스가 제거되었기 때문에 작동하지 않았습니다.
또 다른 가능성이 있습니다. 서비스 파일에서
[Install]
#WantedBy=multi-user.target
주석 처리할 수 있습니다(그런 다음 systemctl daemon-reload). 해당 서비스 파일이 내가 작성했기 때문에 내 서비스에서 작동합니다.
그러나 배포에 속하는 서비스 파일은 에 있습니다 /lib/systemd/system. 이 디렉터리의 파일은 운영 체제에 의해 관리됩니다. 즉, 업데이트로 덮어쓰게 되며 시스템의 다른 부분에서는 이러한 파일이 수정되지 않았다고 가정할 수 있습니다. 단순히 시스템 파일을 편집하는 것은 /etc나쁜 습관이며 나는 그렇게 하고 싶지 않습니다. 나는 내 것을 편집하고 싶지 않습니다 /lib.
무엇을 해야 할까요?
답변1
systemctl disable이를 수행하는 올바른 방법은 실행 systemctl --all해야 하는 모든 부팅 가능한 장치를 나열하기 위해 출력 에 표시되지 않더라도 장치를 수동으로 시작할 수 있습니다. systemctl list-unit-files장치를 부팅할 수 없게 만들려면 mask해당 장치가 필요합니다.
$ sudo systemctl stop unbound
$ sudo systemctl status unbound
● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Fri 2019-05-03 13:12:41 CEST; 5s ago
Docs: man:unbound(8)
Main PID: 5320 (code=exited, status=0/SUCCESS)
$ sudo systemctl disable unbound
$ sudo systemctl status unbound
● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:unbound(8)
$ sudo systemctl start unbound
$ sudo systemctl status unbound
● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; disabled; vendor preset: enabled)
Active: active (running) since Fri 2019-05-03 13:13:14 CEST; 1s ago
Docs: man:unbound(8)
Process: 30513 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
Process: 30518 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
Main PID: 30525 (unbound)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/unbound.service
└─30525 /usr/sbin/unbound -d
정말로 원한다면 에 /lib정의된 시스템 제공 서비스를 재정의 /etc하고 파일을 추가하여 원하는 대상을 변경할 수 있습니다. systemctl edit yourunit그러면 원하는 설정만 재정의할 수 있는 편집기가 열립니다. 결과를 오버레이 "조각"으로 올바른 위치에 저장합니다. 시스템 제공 서비스의 재정의되지 않는 설정 업데이트(예를 들어패키지 업그레이드를 통해)는 투명하게 고려됩니다.
답변2
이렇게 긴 답변을 쓰게 될 줄은 몰랐는데, 당신은 systemd로 다양한 시도를 하신 것 같고, 단순히 마법 명령을 한 번 치고 그것이 존재한다는 사실을 잊어버리는 것보다 그것의 메커니즘에 더 관심이 있으신 것 같습니다. 나는 systemd에 관해 많은 이야기를 할 수 있었습니다!
나.
관리 관점에서 Stephen Kitt의 답변은 매우 훌륭하고 철저합니다.관리자로서서비스가 시작되거나 활성화되는 것을 방지하고 싶습니다. systemd 문서 v241에 따르면(참고자료 참조 man 5 systemd.unit):
단위 파일이 비어 있거나(즉, 파일 크기가 0) 에 심볼릭 링크된 경우
/dev/null해당 구성은 로드되지 않고 로드 상태는 "보호"되어 활성화될 수 없습니다. 이 방법을 사용하면 장치가 완전히 비활성화되어 수동으로 시작하는 것조차 불가능해집니다.
systemctl mask정확히 이것이 하는 일: 아래 유닛과 동일한 이름을 가진 심볼릭 링크를 생성 /etc하고 서비스 파일을 에 심볼릭 링크합니다 /dev/null. systemd가 먼저 찾고 /etc(순서는 동일한 매뉴얼의 첫 번째 줄에 나와 있음) 지정된 유닛을 찾기 때문에 장치가 차단된 것을 발견합니다. 이는 이를 위해 설계되었으므로 서비스가 활성화 및 시작되는 것을 방지하려면 이를 사용하십시오. 이는 가장 간단한 단일 명령 솔루션이며 재부팅 후에도 계속 작동합니다.쉽게 할 수 있는 일이라면 단순하게 유지하세요.
둘.
그러나 만약 당신이설계역할이 다음과 같은 상호 의존적 서비스 집합입니다.시스템 빌더systemctl관리자가 되는 것보다 명령을 사용하여 서비스를 non-startable 또는 non-stoppable 로 선언하는 동시에 다른 메커니즘(소켓, dbus 등)이 요청 시 서비스를 시작할 수 있도록 허용하는 것이 합리적입니다 . Systemd에는 이에 대한 설정이 있으며 동일한 설명서에도 설명되어 있습니다 RefuseManualStart=.RefuseManualStop=
부울 매개변수를 사용합니다. true인 경우 장치는 간접적으로만 활성화하거나 비활성화할 수 있습니다. 이 경우 사용자가 요청한 명시적인 시작 또는 종료는 거부되지만, 다른 유닛의 종속성으로 시작 또는 중지되면 시작 또는 종료가 성공합니다. 이는 주로 사용자가 명시적으로 활성화할 의도가 없었던 장치를 실수로 활성화하거나 비활성화할 의도가 없었던 장치를 실수로 비활성화하지 않도록 하기 위한 안전 기능입니다. 이러한 옵션의 기본값은 false입니다.
이러한 서비스를 활성화할 수 있지만 systemctl start운영자 오류를 방지하기 위해 시작(또는 다른 설정의 경우 중지)이 거부됩니다.
삼.
[Install]서비스 파일에서 해당 섹션을 주석 처리하려는 아이디어를 바탕으로 좀 더 자세한 설명이 필요합니다.
[Install]
#WantedBy=multi-user.target
시스템에 자체 서비스가 제공되는 경우에는 이 작업을 수행하지 마십시오., 즉, 유닛 파일이 /lib계층 구조 아래 어딘가에 있을 때입니다! 업그레이드하면 자동으로 덮어쓰거나 변경 사항을 병합하기 위해 수동 개입이 필요합니다. systemd에는 이에 대한 더 나은 메커니즘이 있습니다. 관례적으로(시스템 서비스의 경우) systemd 아래의 디렉터리 /etc는 "yours"이지만 다음 디렉터리는 /lib배포판에 속합니다.
WantedBy=예를 들어 섹션 에서 이 절을 제거 하려면 [Install]시스템에 적합한 메커니즘(명령 사용)을 사용하여 서비스를 일부 조정해야 합니다 sudo systemctl edit servicename.service. systemd는 편집기를 열고 처음에는 파일이 비어 있습니다.
systemd의 다음 유용한 속성은 키워드 값이 목록(예: WantedBy)인 경우 빈 문자열을 할당하면 목록이 재설정된다는 것입니다(버전마다 불일치가 있지만 대부분 작동합니다. 우리의 경우에는 해당). ). 편집기에서 두 줄을 추가합니다.(이것은 시도한 개념을 정교화한 것일 뿐이지만 아직 실행 가능한 솔루션에 도달하지 못했습니다. 마스킹을 통해 원하는 결과를 얻을 수 있다는 것을 이미 알고 있습니다.):
[Install]
WantedBy=
그러면 WantedBy목록이 빈 상태로 재설정됩니다. 다른 종속성을 추가하려면 동일한 키를 사용하여 다른 행을 추가하면 됩니다( WantedBy=another.service잘못 생각한 예에서는 다른 행). 실제로 뒤에서 일어나는 일은 systemd가 생성합니다.씌우다파일은 /etc다음 위치에 있습니다.당신의, 기계 소유자의 디렉토리이며 절대 건드리지 않겠다고 약속했습니다. 기본 디렉토리 레이아웃이 .systemd라고 가정하면 생성된 파일의 이름은 입니다 /etc/systemd/system/servicename.service.d/override.conf. 여기에 해당 부분이 있습니다.서비스 이름.서비스재정의하려는 조직의 정확한 이름입니다. systemd는 패턴과 일치하는 이 새 하위 디렉터리의 모든 파일을 존중하므로 *.conf단순한 것 이상의 파일이 있을 수 있습니다 override.conf. (표시된 것처럼 가장 낮은 것부터) 이름별로 사전순으로 적용됩니다 ls -1 *.conf | LC_ALL=C sort.
이는 귀하의 경우에는 올바른 메커니즘이 아니지만 Peter가 이미 후속 설명에서 답변한 것처럼 때로는 환경 변수를 추가하거나 환경 변수만 추가하려고 할 때 도움이 될 수 있습니다.오류 해결1. 좋아요
$ cat /etc/systemd/system/systemd-remount-fs.service.d/override.conf
# Workaround for the systemd bug #14603: remount-fs and growfs@
# race, so that the latter may fail because the root fs is still
# readonly. This dependency ensures that the remount happens first.
[Unit]
[email protected]
다음 명령을 사용하여 재정의가 장치 구성에 병합되었는지 확인할 수 있습니다.systemctl show myunit.service. 출력은 매우 장황하므로 grep을 사용하십시오.
$ systemctl show systemd-remount-fs.service | grep ^Before=
Before=systemd-update-utmp.service [...] [email protected] [...]
줄이 상당히 길기 때문에 이것은 세상에서 가장 명확한 예는 아닙니다. 마크업에서 대부분을 제거했지만 [...]목록에서 찾을 수 있습니다. [email protected]다른 시작/중지/시작/최대 절전 모드 및 기타 시나리오를 시도하기 전에도 항상 구성 변경 사항이 실제로 장치의 결합 설정에 통합되었는지 확인하는 것이 가장 좋습니다. 맞춤법 오류가 발생합니다.
4.
물론 서비스뿐만 아니라 타이머, 소켓, 마운트 등 모든 유형의 장치를 조정할 수 있습니다. 짝수 유닛 파일동적으로 생성됨디렉토리 아래의 /run이러한 조정 사항을 준수하십시오 . 예를 들어, 다음 경우에는 일반 마운트가 사용되지만 systemd는 /optRAM 파일 시스템 디렉터리에 이에 대한 /etc/fstab임시 장치를 생성합니다 . 이 임시 단위는 완벽하게 식별합니다.opt.mount/run/systemd/system추가 Wants=명칭/etc/systemd/system. 그런데 원하는 서비스는 예시입니다옳은사용 RefuseManualStart및RefuseManualStop: 파일 시스템이 마운트 및 마운트 해제되는 동안에만 작업을 수행해야 하며 /opt, 수동으로 시작하면 중단되거나 오류가 발생합니다. 더 나쁜 것은 그것이다.습관/opt파일 시스템을 수동으로 시작한 경우 파일 시스템을 마운트한 후 즉시 시작하십시오!
BindsTo=opt.mount또한 서비스는 및 를 지정하여 "강력한 바인딩" 모드를 표시합니다 After=opt.mount. systemd.unit(5) 매뉴얼을 인용하여 "[UNIT] SECTION OPTIONS/BindsTo=" 아래에 언어를 더 쉽게 이해할 수 있도록 추가 내용을 괄호 안에 넣었습니다.
BindsTo=의 동작은 동일한 셀 [,]에서 After=와 함께 사용될 때 더욱 강력해집니다. 이 경우, [유닛이] 바인딩된 유닛은 [반드시] 활성화되어야 하며, 해당 유닛도 [그리고 유지] 활성화되어 있습니다.
여기서 의미하는 바는 장치가 정지한 후에 시작하고 opt.mount정지하기 전에 엄격한 속도로 정지한다는 것입니다.
** **
systemd는 크고 강력하며 유연한 시스템입니다. 가능한 최선의 방법으로 시스템을 조정하고 있다면 man다른 일이 지루할 때 웹에서 문서를 읽는 것이 확실히 도움이 될 수 있습니다.
1 이 버그는 1년 전에 수정되었으며 수정 사항이 systemd 버전 245에 포함되었지만 여러 배포본을 집계하고 때로는 이전 이미지의 VM을 집계하고 있기 때문에 유지해야 합니다. Debian 10에는 systemd 접두사 v241이 있습니다. Debian 11에만 v247이 함께 제공됩니다. 프로덕션 시스템은 업그레이드 속도가 느리므로 솔루션은 몇 년 더 유지하는 것입니다.