"systemctl start"는 역방향 종속성 장치를 시작하지 않지만 "systemctl restart"는 시작합니다.

"systemctl start"는 역방향 종속성 장치를 시작하지 않지만 "systemctl restart"는 시작합니다.

나는 systemd fw.service단위 파일을 가지고 있으며 이는 다음 요구 사항입니다 networking.service.

# systemctl show networking -p Requires
Requires=system.slice fw.service
# 

networking.service해당 active상태에서 실행 하면 systemctl stop fw몇 초 후에 해당 상태가 유지 systemctl start fw됩니다 . 그러나 상태 에서 실행 하면 다시 시작됩니다.networking.serviceinactive (dead)networking.serviceactivesystemctl restart fwnetworking.service

이것이 예상되는 동작입니까? 내 생각 systemctl restart엔 기본적으로 systemctl stop아슬아슬한 순간 systemctl start이므로 systemctl start출시되어야 한다고 생각합니다 networking.service.

답변1

restartstop+ 와 유사 start하지만 동일하지는 않습니다. 작업은 서비스 관리자 restart내에서 다르게 처리됩니다 systemd. systemctl인터페이스의 단순한 편의 기능이 아닙니다 . [*]

이 특정 동작으로 판단하면 현재 버전의 man systemd.unit.(적어도 내 설치에서는 systemd-239)입니다.

행동이 stop문서화되었습니다. 그리고 동작은 start문서와도 일치합니다. 명시적으로 문서화되지 않은 것은 restart필요한 단위로의 전파 입니다 fw.service. 그러나 다른 유형의 종속성에서 이에 대한 힌트를 보았습니다.

부분 =

와 유사하게 종속성을 구성 Requires=하지만 장치를 중지하고 다시 시작하는 것으로 제한됩니다. systemd가 여기에 나열된 장치를 중지하거나 다시 시작하면 작업이 해당 장치에 전파됩니다. 이는 단방향 종속성입니다. 이 장치를 변경해도 나열된 장치에는 영향을 미치지 않습니다.

힌트는 PartOf=가 의 제한된 하위 집합 인 경우Requires= 모든 작업이 수행된다는 것입니다. 따라서 여기에는 전파 재시작이 포함됩니다.Requires=PartOf=

networking.service첫 번째 단계에서 멈추고 싶지 않다면 로 대체할 수 Requires=fw.service있습니다 Wants=fw.service. 하지만 Requires=방화벽 규칙이 활성화되지 않으면 네트워크가 절대 활성화되지 않도록 하기 위해 의도적으로 사용된 것 같습니다 .

재부팅이 순차적으로 이루어지도록 networking.service설정하여 활성화 없이는 활성화되지 않도록 할 수도 있습니다. 실제로 그런 일이 일어나는지는 확인하지 못했습니다. (그것이 당신이 바라는 것이라면 이 답변이 아닌 다른 기관에 대해 검증하는 것이 좋습니다 :-).fw.serviceAfter=fw.service

정말로 원한다면 이미 설정해 놓을 수도 있을 Wants=networking.service것 같습니다 . 이는 이러한 종속성이 특정 순서를 의미하지 않기 때문에 가능합니다. 내 생각에는 시스템에 충돌이 있는 경우에만 "종속성 순환" 문제가 있는 것 같습니다.fw.servicenetworking.serviceRequires=fw.service주문하다종속성 - After=Before=설정.


[*] systemd-logind예 를 들어다시 시작할 수 있도록 설계됨, systemd재부팅 후에도 특정 중요한 파일을 열어두도록 조정합니다. 하지만 로그인만 하면 stop열려 있는 파일이 손실됩니다. (내가 아는 한 systemd-logind를 다시 시작하면 Xorg 또는 Wayland의 모든 현재 버전이 여전히 중단되지만 systemd코드가 아이디어를 다르게 처리하는 것을 볼 수 있습니다 restart:-P).

관련 정보