습관. systemd에 관한 한 프로세스는 다른 컨텍스트에서 실행됩니다.

실제로 이는 데스크톱 버스 서비스 활성화를 피해야 하는 이유 중 하나입니다. systemd에 관한 한 데스크탑 버스 에이전트에 의해 직접 생성된 서비스 프로세스는 해당 서비스의 일부입니다.

사람들은 적절한 권한을 통해 제어 그룹 간에 프로세스를 이동할 수 있습니다. 그러나 이는 작업의 절반일 뿐이며, 나머지 절반은 systemd가 유닛이 시작되지 않았을 때 유닛을 시작했다고 믿게 만들고 내부 데이터 구조를 다시 작성하는 데 필요한 부분이 제공되지 않습니다.

이는 systemd의 모델이 아닐 뿐만 아니라 대부분의 서비스 관리 하위 시스템의 모델도 아닙니다.

그런데 너무 많은 사람들이 Oracle 소프트웨어를 "괜찮은" 서비스 단위로 생각하지만 실제로는 그렇지 않습니다.공포의 집지역.

추가 읽기

• systemctl 이외의 메커니즘을 통해 데몬이 시작된 경우 systemctl은 데몬의 상태를 정확하게 보고할 수 없습니다.
• systemd를 사용하여 Java 데몬 구성
• https://unix.stackexchange.com/a/437461/5132
• 조나단 데보인 폴라드(2016).데스크탑 버스(D-Bus) 버스 활성화 방지 . 무언가를 먹다. 소프트웨어.
• 조나단 데보인 폴라드(2015). 시스템화 된 공포의 집. 자주 주어지는 답변입니다.

간단히 말해서, systemd 자체에서 서비스를 시작하지 않는 한 systemd가 서비스 시작을 고려하도록 할 방법이 없습니다. systemd의 요점 중 하나는 서비스를 일관되게 관리하는 것이며, 서비스를 시작하는 다양한 방법을 갖는 것은 그 아이디어에 어긋납니다.

이제 시스템은하다외부에서 시작된 프로세스를 관리하기 위한 조항이 있는데, 이는 귀하가 설명하는 상황에 어느 정도 적절해 보입니다. 이것은 실제로 별도의 단위입니다.범위 단위.

범위 단위를 사용하려면 여전히 systemd와의 외부 시스템 상호 작용이 필요합니다. 범위 단위는 systemd에 대한 D-Bus 요청을 통해서만 시작될 수 있고 범위의 초기 프로세스로 사용할 PID를 전달할 수 있기 때문입니다. 또한 범위 단위를 시작할 때 systemd는 여전히 cgroup 자체를 생성할 것으로 예상합니다(그런 다음 전달된 PID를 생성된 cgroup으로 이동합니다). 따라서 systemd에서 이러한 프로세스를 관리하려면 새 프로세스를 범위로 생성하는 애플리케이션에 대한 지원이 필요합니다.

즉, 서비스를 시작하는 데 두 가지 다른 방법을 사용하지 마십시오. 꼭 필요한 경우에만 타사 서비스 관리자를 사용하세요.

해결하려는 문제가 부팅 중에 서비스를 시작하는 것이라면 다음을 수행하세요.

1. 타사 관리자(귀하의 경우 Oracle NodeManager)가 시작 시 서비스 구성을 지원하는지 확인하세요. 서비스를 관리하므로 시작 중에도 서비스를 관리해야 합니다.

2. systemd를 사용하는 경우 간단한 oneshot서비스 단위를 사용하고 타사 관리자에게 서비스 시작을 요청하세요. 이는 일부 API 또는 RPC(아마도 HTTP를 통해)를 통해 제3자 관리자(귀하의 경우 Oracle NodeManager)에 연락하고 서비스를 시작하라고 지시하는 것을 의미합니다.

시작을 위해 systemd를 사용하는 경우 장치 이름을 적절하게 지정(예: "start-foo", "initial-foo" 또는 "foo-startup")하여 "시작" 상태로 유지되지 않고 (기본값) 상태 로 oneshot유지된다는 점을 분명히 합니다. 값)이므로 장치 상태를 확인하면 성공적으로 완료되었다는 것만 표시되므로 타사 관리자에서 실행 중인 서비스 상태를 반영한다고 혼동할 일이 없습니다.RemainAfterExit=no