I found that the created zombies are owned by root and the frontend
does not run with root privileges. I think, this may be the reason.

The reason why zombies are created is that we are effectively
replacing backend by what execl calls. We may be able to solve the
issue by allowing the backend to continue running when execl is used
and at the end call wait() if that is possible.

Edward

On 03/09/2015, Steve Litt <slitt@???> wrote:
> On Thu, 3 Sep 2015 07:38:13 +0100
> Edward Bartolo <edbarx@???> wrote:
>
> I'd figure out how to stop those zombies from happening in the first
> place. It's pretty hard to create a zombie: I think you have to
> doublefork and then terminate. In that case, if you're using a good
> init system, I believe you can send PID1 a SIGCHLD, and PID1 will reap
> zombies. I know that's how suckless-init works. I suggest you download
> Suckless-Init and look at its source: It's only 83 non-blank lines.
>
> But again, I think the question "how do I reap zombies" is a little
> like "how do I sweep up broken glass", when you're dropping and
> breaking 3 glasses every day. The better question is "why am I dropping
> these glasses?"
>
> SteveT
>
>
>> I am trying to reap zombies. The "while(fpwaitpid" pascal code is
>> freezing my application.
>>
>> *********************************************************************************
>> procedure handle_sigchld(sig: longint; info: psiginfo; context:
>> psigcontext); cdecl;
>> var
>> Status: cint;
>> a_pid: pid_t;
>> begin
>> Status := 0;
>> a_pid := -1;
>>

>> // This is freezing my application
>>   while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
>>   begin
>>     backend_lives := backend_lives + 1;
>>     showmessage('hi strunz!!!');
>>   end;
>> end;

>>
>>
>> var sa: sigactionrec;
>>
>> initialization
>> sa.sa_handler := @handle_sigchld;
>> fpsigemptyset(&sa.sa_mask);
>>

>>   sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
>>   if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
>>   begin
>>     // do nothing
>>   end;
>> ******************************************************

>>
>> Any ideas?
>>
>>
>> Edward
>>
>>
>>
>> On 02/09/2015, Steve Litt <slitt@???> wrote:
>> > Personally, I'd go waaaaay out of my way never to multithread unless
>> > there were a huge reason to do so. Your app does such a small, quick
>> > job that there's no reason.
>> >
>> > You mentioned the front and back end communicating with each other,
>> > and everyone mentioned fifos. I agree. And if there's a reason for
>> > one program to tell the other that info's ready for it, that's what
>> > SIGUSR1 and SIGUSR2 are for. Or at least what *I* use them for.
>> >
>> > SteveT
>> >
>> > Steve Litt
>> > August 2015 featured book: Troubleshooting: Just the Facts
>> > http://www.troubleshooters.com/tjust
>> >
>> >
>> > On Wed, 2 Sep 2015 19:45:08 +0100
>> > Edward Bartolo <edbarx@???> wrote:
>> >
>> >> What about multithreading? Should I do away with it and let the
>> >> frontend monitor for zombies to call waitpid?
>> >>
>> >> Edward
>> >>
>> >> On 02/09/2015, Steve Litt <slitt@???> wrote:
>> >> > On Wed, 2 Sep 2015 11:47:34 +0100
>> >> > Edward Bartolo <edbarx@???> wrote:
>> >> >
>> >> >> Hi all,
>> >> >>
>> >> >> I think, I found an alternative to multithreading in netman.
>> >> >> This is using interprocess communication, although what I have
>> >> >> in mind may not be proper interprocess communication.
>> >> >>
>> >> >> The idea is this: the backend would be converted into some sort
>> >> >> of a daemon exporting one function and importing another one.
>> >> >> The frontend would use the exported function from the backend
>> >> >> to send it commands. The backend would do the same thing with
>> >> >> the exported function from the frontend:
>> >> >>
>> >> >> Visually, this is as follows:
>> >> >>
>> >> >> Frontend -------------->> Backend
>> >> >> Frontend <<-------------- Backend
>> >> >>
>> >> >> In my humble opinion, this may help getting rid of having to use
>> >> >> multithreading to avoid temporary frontend deadlocks. It also
>> >> >> solves the issue with zombies being created, and would permit me
>> >> >> create a responsive application but using the KISS principle.
>> >> >
>> >> > I like it. A lot!
>> >> >
>> >> > IMHO the front end should do nothing but display ESSIDs with
>> >> > strength and encryption, letting you click on the one you want or
>> >> > right click and say "turn off" to turn it off.
>> >> >
>> >> > If you've already dealt with that ESSID, the back end has the
>> >> > password and uses it to join that ESSID. If the back end hasn't
>> >> > dealt with it, it sends the front end a message saying "get me
>> >> > the password", the front end queries the user for the password,
>> >> > and the front end sends it back to the back end. Assuming one
>> >> > user, this doesn't even have to be stateful, but if it has to be
>> >> > stateful, there are a million ways to do it.
>> >> >
>> >> > I like it!
>> >> >
>> >> > SteveT
>> >> >
>> >> > Steve Litt
>> >> > August 2015 featured book: Troubleshooting: Just the Facts
>> >> > http://www.troubleshooters.com/tjust
>> >> > _______________________________________________
>> >> > Dng mailing list
>> >> > Dng@???
>> >> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>> >> >
>> >
>> >
>> > _______________________________________________
>> > Dng mailing list
>> > Dng@???
>> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>> >
>
>
>
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>