나는 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.service
inactive (dead)
networking.service
active
systemctl restart fw
networking.service
이것이 예상되는 동작입니까? 내 생각 systemctl restart
엔 기본적으로 systemctl stop
아슬아슬한 순간 systemctl start
이므로 systemctl start
출시되어야 한다고 생각합니다 networking.service
.
답변1
restart
stop
+ 와 유사 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.service
After=fw.service
정말로 원한다면 이미 설정해 놓을 수도 있을 Wants=networking.service
것 같습니다 . 이는 이러한 종속성이 특정 순서를 의미하지 않기 때문에 가능합니다. 내 생각에는 시스템에 충돌이 있는 경우에만 "종속성 순환" 문제가 있는 것 같습니다.fw.service
networking.service
Requires=fw.service
주문하다종속성 - After=
및 Before=
설정.
[*] systemd-logind
예 를 들어다시 시작할 수 있도록 설계됨, systemd
재부팅 후에도 특정 중요한 파일을 열어두도록 조정합니다. 하지만 로그인만 하면 stop
열려 있는 파일이 손실됩니다. (내가 아는 한 systemd-logind를 다시 시작하면 Xorg 또는 Wayland의 모든 현재 버전이 여전히 중단되지만 systemd
코드가 아이디어를 다르게 처리하는 것을 볼 수 있습니다 restart
:-P).