First of all, thanks for taking the time to write to me.
Using "ps xao pid,ppid,comm", I found what I described to you:
precisely, that orphaned processes were adopted by the GUI frontend.
The frontend's pid was listed as the zombies' ppid. Now, this issue
has little effect on the code as I am using the WaitOnExit for any
behind the scenes processes. Using a second thread to call the
backend, enabled me to use WaitOnExit without affecting the frontend.
The pasted listing is a listing by ps. You can see that ifup, ifdown
and backend have actually inherited their grandfather's pid.
$ ps xao pid,ppid,comm
PID PPID COMMAND
1 0 init
2 0 kthreadd
3 2 ksoftirqd/0
5 2 kworker/0:0H
7 2 rcu_sched
8 2 rcu_bh
9 2 migration/0
10 2 watchdog/0
11 2 watchdog/1
12 2 migration/1
13 2 ksoftirqd/1
15 2 kworker/1:0H
16 2 khelper
17 2 kdevtmpfs
18 2 netns
19 2 khungtaskd
20 2 writeback
21 2 ksmd
22 2 khugepaged
23 2 crypto
24 2 kintegrityd
25 2 bioset
26 2 kblockd
27 2 kworker/0:1
28 2 kworker/1:1
29 2 kswapd0
30 2 fsnotify_mark
36 2 kthrotld
37 2 ipv6_addrconf
38 2 kworker/0:2
39 2 deferwq
73 2 khubd
76 2 acpi_thermal_pm
77 2 ata_sff
78 2 scsi_eh_0
79 2 scsi_tmf_0
80 2 scsi_eh_1
81 2 scsi_tmf_1
82 2 kworker/u8:2
83 2 kworker/u8:3
84 2 scsi_eh_2
85 2 scsi_tmf_2
86 2 scsi_eh_3
87 2 scsi_tmf_3
92 2 kworker/1:2
94 2 kworker/1:1H
95 2 kworker/0:1H
117 2 jbd2/sda9-8
118 2 ext4-rsv-conver
308 1 udevd
365 2 hd-audio0
372 2 kpsmoused
379 2 cfg80211
1276 1 rpcbind
1304 1 rpc.statd
1309 2 rpciod
1311 2 nfsiod
1318 1 rpc.idmapd
1555 1 privoxy
1563 1 rsyslogd
1601 1 atd
1631 1 acpid
1669 1 cron
1727 1 dbus-daemon
1969 1 exim4
1989 1 slim
2015 1989 Xorg
2016 1 getty
2017 1 getty
2018 1 getty
2019 1 getty
2020 1 getty
2021 1 getty
2034 2 kauditd
2036 1 console-kit-dae
2103 1 polkitd
2114 1989 sh
2166 2114 ssh-agent
2169 1 dbus-launch
2170 1 dbus-daemon
2180 2114 xfce4-session
2182 1 xfconfd
2186 1 gpg-agent
2187 2180 xfwm4
2189 2180 xfce4-panel
2191 1 xfsettingsd
2193 1 syndaemon
2195 2180 xfdesktop
2199 1 xfce4-power-man
2203 1 xscreensaver
2206 1 xfce4-power-man
2209 1 xfce4-volumed
2212 1 upowerd
2223 2189 panel-6-systray
2239 2189 panel-2-actions
2377 2189 iceweasel
2398 1 at-spi-bus-laun
2407 2189 xchat
2571 2 kworker/0:0
2572 2 kworker/1:0
2607 1 Thunar
2611 1 tumblerd
2616 1 netman
2633 2616 backend <defunct>
2643 2616 ifdown <defunct>
2663 2 kworker/0:3
2664 2 kworker/0:4
2698 1 xfce4-terminal
2702 2698 gnome-pty-helpe
2703 2698 bash
2791 2616 ifup <defunct>
2801 1 wpa_supplicant
2823 2 kworker/u8:0
2843 1 dhclient
3044 2703 ps
As you can see, the listed zombies have inherited their grandfather's
pid as their ppid.
On 05/09/2015, Rainer Weikusat <rainerweikusat@???> wrote:
> Edward Bartolo <edbarx@???> writes:
>> I am not putting in doubt what you are telling me.
>
> You are. And you are - pardon my frankness - very much confused
> regarding how 'processes and process relationships' work on UNIX(*)/
> Linux. I'll try to clear this up but you might want to consider getting
> yourself a good book on the topic.
>
>> In my implementation, the backend is run from within the code of the
>> frontend, so its ppid is the pid of the frontend.
>
> This is correct.
>
>> Occurrences of execl, create another child process which is owned by
>> the backend, but the latter, dies as soon as the child process is
>> created.
>
> This isn't: execl doesn't create a child process associated with the
> process invoking it but it makes this process execute a new program. You
> can see this for yourself. Save the following two C source code files to
> some directory as a.c and b.c.
>
> ---- a.c -----
> #include <stdio.h>
> #include <unistd.h>
>
> int main(void)
> {
> printf("I'm program-1, my pid is %lu and my parent is %lu\n", getpid(),
> getppid());
> execl("./program-2", "p2", (void *)0);
> return 0;
> }
> --------------
>
> ---- b.c ----
> #include <stdio.h>
> #include <unistd.h>
>
> int main(void)
> {
> printf("I'm program-2, my pid is %lu and my parent is %lu\n", getpid(),
> getppid());
> return 0;
> }
> -------------
>
> compile them into exectuables named program-1 and program-2 via
>
> gcc -o program-1 a.c
> gcc -o program-2 b.c
>
> and run program-1. The output should be (with different actual pids, of
> course)
>
> [rw@doppelsaurus]/tmp#./program-1
> I'm program-1, my pid is 8935 and my parent is 3395
> I'm program-2, my pid is 8935 and my parent is 3395
>
>> The orphaned child is related to the frontend, but its direct parent
>> being dead, is assigned the pid of the frontend as its parent.
>
> Orphaned child processes don't become children of the parent of their
> original parent, they become children of init/
> the-process-with-pid-1. init mostly just executes a wait-loop in order
> to collect (and ignore) the exit status of any process assigned to it in
> this way to prevent them from turning into zombies.
>
>> The complications arise considering the fact, that the backend runs with
>> root
>> privileges,
>
> [...]
>
>> It seems, the fact that child processes created by instances of the
>> backend, are thus owned by root, and the frontend is not permitted to
>> wait() and reap them.
>
> As the example program from my last mail should have demonstrated:
> This is also wrong. A process can collect the status of one if its
> children even if the child is executing under a different euid and if
> this different euid happens to be 0.
>
> BTW: Despite I don't have a WiFi-capable computer here, I cloned the
> edbarx/netman.git repository to see if I could perhaps fix
> this. However, the code available via
>
> https://git.devuan.org/edbarx/netman.git
>
> doesn't compile. The backend_src/bin and backend_src/obj directories are
> missing. This is likely due to a misfeature (IMO) of all SCMs I've been
> using so far, namely, they drop empty directories. You can avoid this by
> creating a dummy file in both, eg,
>
> touch backend_src/obj/.keep
> touch backend_src/bin/.keep
>
> and check them into git like this
>
> git add backend_src/obj/.keep backend_src/bin/.keep
> git commit -a -m 'directories needed by the build system'
>
> After doing this, the build aborts with
>
> backend.pas(96,13) Error: Identifier not found "RunCommand"
>
> (occurs a couple of times). I could fix this but since this seems like a
> minor oversight to me, I suggest that you put the missing stuff into the
> public repository instead.
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
::
Re: [DNG] Doing away with multi-thr…
