흥미로운 (적어도 나에게) 문제가 있습니다. 특정 경우에 손자 프로세스에 대한 정보를 안정적이고 이식 가능한 방법으로 찾을 수 없습니다. 응용 프로그램, AllTray, 그 특정 하위 프로세스가 자식 생성하고 다음 죽을 특정 이상한 경우 작동하도록 노력하고있어. AllTray의 작업은 기본적으로 AllTray가 호출 할 명령 줄 (일반적으로 alltray xterm은 xterm을 시작하고 AllTray에서 관리)으로 지정된 작업 트레이에 응용 프로그램을 도킹하는 것입니다.어떻게 POSIX 시스템에서 하위/손자 프로세스를 안정적으로 추적합니까?
대부분의 GUI 소프트웨어는 잘 작동합니다. _NET_WM_PID 속성을 해당 창 (또는 위젯 라이브러리가 해당)에 설정하고 모두 _NET_WM_PID == fork() 자식을 처리 했으므로 잘 설정됩니다. 그러나 oowriter 또는 K3b와 같은 KDE에서 실행되도록 작성된 소프트웨어와 같이 일부 경우 AllTray가 실행하는 하위 프로세스는 쉘 스크립트 (OO.o의 경우와 같이)이거나 이상한 부모 과정이 매우 일찍 종료되기 때문에 fork()과 exec() 자체가 효과적으로 배경을 이루게됩니다.
나는 프로세스 테이블에서 손자를위한 부모 프로세스 ID를 보존하기 위해 내 자식 프로세스를 얻지 않을 생각을 가졌으므로 맨 아래에서 맨 아래로 가계도를 가로 질러 그들을 다시 연결할 수있었습니다. 상단. 그래도 작동하지 않습니다. 일단 내 자식 프로세스가 죽고 좀비가되면 시스템에서 내 손자 프로세스를 고아로 간주하고 init을 채택합니다. 이것은 적어도 Linux 2.6 및 NetBSD의 경우 인 것으로 보입니다. 아마 표준이라고 추정 할 수 있습니다. POSIX는 그 점을 명시하지 않은 것 같습니다. 그래서 나는 그 반대를 기대하고있었습니다.
이 방법은 효과가 없으므로 LD_PRELOAD을 사용하고 내 자식 프로세스 '를 가로 챈 다음 fork()으로 전화를 걸어 정보를 부모 프로세스로 전달합니다. 그러나 이상적인 솔루션만큼 이식성이 떨어지는 것은 아닌지 염려합니다. 다른 시스템은 동적 링커가 LD_PRELOAD과 같은 작업을 수행하는 방식에 따라 서로 다른 규칙을 사용하기 때문입니다. 적어도 Linux 시스템에서는 setuid/setgid GUI 응용 프로그램의 경우도 도우미 라이브러리가 setuid 또는 setgid가 아닌 경우 작동하지 않습니다. 일반적으로, 그것은 나에게 나쁜 생각 인 것처럼 냄새를 맡고, 상당히 hackish하다고 느낀다.
그래서, 나는 누군가가이 작업을 수행하거나 LD_PRELOAD 같은 메커니즘에 의존의 아이디어는 정말 유일한 옵션입니다 만약 내가하지가고 인 (커널 패치의 짧은해야하는 방법에 대한 아이디어를 가지고 바라고 있어요 일어날).
Hrm. 이것에 대해 살펴보고 무슨 일이 일어나는 지 봅시다. 아이디어는 좋게 들린다.새로운 단일 프로세스 그룹을 만드는 것이 불충분 할 이유가 있습니까? 현재 AllTray는 하나의 응용 프로그램 만 관리하며 궁극적으로는 더 많은 관리를 할 것입니다. 단 한 번의 pgid만으로도 충분히 보완해야 할 프로세스를 찾을 수 있다면 충분할 것입니다. –
래퍼가 kdeinit를 통해 KDE <=3 or > 4.3을 실행하거나 Firefox가 이미 다른 창을 열어 놓은 경우 Firefox가 시작되는 경우이 작업이 실패하는 것으로 상상할 수 있습니다.이 경우 완전히 다른 트리의 프로세스가 새 창을 만듭니다. – ephemient
@ephemient KDE 앱이 이상한 일을한다는 것을 알고 있으며, 내가 고치려는 경우 중 하나입니다. 이미 프로세스가 실행 중일 때 FF 나 GNOME 터미널에 대해서는 할 수있는 일이별로 없지만 사용자가 의미하는 것을 수행하려고 시도한 몇 가지 아이디어가 있지만 생각은 * 가능합니다. –