:: Re: [DNG] Doing away with multi-thr…
Top Pagina
Delete this message
Reply to this message
Auteur: Edward Bartolo
Datum:  
Aan: Rainer Weikusat
CC: dng
Onderwerp: Re: [DNG] Doing away with multi-threading in my project (netman)
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
>