Edward Bartolo writes:
> Quote: < process (that's done via fork and not via execve) and it's not adopted
> by the grand parent but by init.>>
>
> So what is the difference between an "orphaned process", i.e. a
> process whose parent has exited after giving birth to a child process
> and one which
On Sat, Sep 05, 2015 at 08:52:39PM +0100, Edward Bartolo wrote:
> Quote: < process (that's done via fork and not via execve) and it's not adopted
> by the grand parent but by init.>>
>
> So what is the difference between an "orphaned process", i.e. a
> process whose parent has exited after giving
On Sat, Sep 05, 2015 at 08:52:39PM +0100, Edward Bartolo wrote:
> Quote: < process (that's done via fork and not via execve) and it's not adopted
> by the grand parent but by init.>>
>
> So what is the difference between an "orphaned process", i.e. a
> process whose parent has exited after giving
Correction:
Sorry, but it looks there is only a very subtle difference between the
two. The only difference I see, is that, since in the case of execl,
the parent effectively is replaced, i.e. dies, the child process is awarded its
parent PID. This is not the case when a parent process creates a c
Quote: <>
So what is the difference between an "orphaned process", i.e. a
process whose parent has exited after giving birth to a child process
and one which replaces the original process effectively giving its
parent a death sentence?
Sorry, but it looks there is only a very subtle difference be
Edward Bartolo writes:
[...]
> Using "ps xao pid,ppid,comm", I found what I described to you:
> precisely, that orphaned processes were adopted by the GUI frontend.
There are no 'orphaned processes' in this case because execl does not
create a new process. It runs a new program in the same proc
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 usi
Edward,
A rather thorough reference is "The Linux Programming Interface"
available from: http://www.man7.org/tlpi/ and other retailers.
HTH,
- Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and m
Edward Bartolo 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
I am not putting in doubt what you are telling me. In my
implementation, the backend is run from within the code of the
frontend, so its ppid is the pid of the frontend. Occurrences of
execl, create another child process which is owned by the backend, but
the latter, dies as soon as the child proce
Edward Bartolo writes:
> A periodic algorithm is now implemented in the frontend to search for
> backend and any spawned children for ownership by root. This most
> probably was what was causing waitpid and wait to fail to reap
> zombies.
It can't. As an experiment, copy the id program to /tmp an
Oooop, the algorithm is not periodic, but is used whenever the user
clicks connect and disconnect. Other operations can also be included.
On 04/09/2015, Edward Bartolo wrote:
> A periodic algorithm is now implemented in the frontend to search for
> backend and any spawned children for ownership b
A periodic algorithm is now implemented in the frontend to search for
backend and any spawned children for ownership by root. This most
probably was what was causing waitpid and wait to fail to reap
zombies. If the algorithm find a root process parented by the
frontend, it will disable 'connect' an
Edward Bartolo writes:
> Hi,
>
> For the last days I have been struggling to reap zombies adopted by
> the frontend with only failures.
The frontend doesn't adopt zombies. Only init ever does that.
> I tried several methods using wait(-1), waidpid and trapping the
> signal when a child dies wi
Tomorrow, I will make it a point to push my multithreaded version of
netman for evaluation. You will see multithreading did not add much
complexity with the benefit of better frontend responsiveness and no
zombies lurking around.
On 03/09/2015, Edward Bartolo wrote:
> I kept a multithreaded netma
I kept a multithreaded netman version installed on my computer so that
I would be able to connect to wifi with a couple of button clicks. All
I can say is, that it doesn't create zombies and it is well behaved.
What we should do is do away with execl which *replaces* backend
effectively killing it
On Thu, 3 Sep 2015 18:24:51 +0100
Edward Bartolo wrote:
> 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
On Thu, Sep 03, 2015 at 06:53:46PM +0100, KatolaZ wrote:
[cut]
>
> OK, I admit it might had been a tad too cryptic, but my intentions
> were good. What I mean is that the parent has to set a handler for
> SIGCHLD, and the handler has to call wait() [or waitpid(-1, &status)]
> to reap the dead ch
On Thu, Sep 03, 2015 at 06:36:39PM +0100, KatolaZ wrote:
[cut]
>
> Sorry guys, I didn't get through the whole thread, but I wanted to say
> just one obvious thing: if your program works correctly, then it is
> *very* difficult (if not impossible) to create and leave zombies
> around. If the prog
On Thu, Sep 03, 2015 at 06:24:51PM +0100, Edward Bartolo wrote:
> 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
On 03/09/2015 18:35, Steve Litt 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.
Nope, a zombie is actually very easy to create:
- have a process parent that spawns a chil
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
On Thu, 3 Sep 2015 07:38:13 +0100
Edward Bartolo 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
Hi,
For the last days I have been struggling to reap zombies adopted by
the frontend with only failures. I tried several methods using
wait(-1), waidpid and trapping the signal when a child dies without
ever succeeding to reap zombies. This means, I will stop and will
leave the issue open to anyon
hmm, I do wifi connect in bash/xterm
one shot
sudo vi /etc/network/interfaces
add
source /etc/network/interfaces.d/*.cfg
if not already there
make sure /etc/network/interfaces.d folder exists
later, check what is available
sudo iwlist wlan0 scanning |grep -e ESSID -e Quality
Edward Bartolo writes:
> 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
Sorry,
come to think about it, simply return if rv is -1,
because that means there are no un-waited children left.
You should definately first fix the pcint Status issue,
because if you give an invalid argument ot waitpid, it
returns -1 and sets errno to EINVAL.
while true
rv := waitpid(-1,
Hi Edward,
AFAIK Status must be a pointer, because fpwaitpid will write
information into that status.
Also, you should check the return value of fpwaitpid():
0 : nothing has happened
-1: an error occurred, check fgGetErrno
other: the pid of a child where something happened
so like (pseudoco
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;
begi
On 09/02/2015 10:27 PM, Steve Litt wrote:
> Personally, I'd go way 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 everyo
Personally, I'd go way 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 f
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 wrote:
> On Wed, 2 Sep 2015 11:47:34 +0100
> Edward Bartolo wrote:
>
>> Hi all,
>>
>> I think, I found an alternative to multithreading in netman. This
On Wed, 2 Sep 2015 11:47:34 +0100
Edward Bartolo 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
I found this code in gensigset.inc and signals.inc fpc source library.
Is this what we are talking about?
function FPSigaction(
sig: cint;
act: psigactionrec;
oact: psigactionrec
):cint;
function fpsigemptyset(var nset : tsigset):cint;
var i :longint;
Begin
for i:=0 to wordsinsigset-1 DO
Quote: "This means the GUI/ frontend
either needs to handle SIGCHLD in order to get notified when a child
process terminates so that a suitable wait call (which doubtlessly exists in the
Free Pascal libraries) can be used to get rid of the zombie without
having to wait for it or (the by far most si
Edward Bartolo writes:
[...]
> 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 expor
Hi,
Thanks for the reply. If Unix Domain Sockets can do the job nicely,
why not? However, I will wait for other replies for their opinion.
Thanks.
On 02/09/2015, dr.kl...@gmx.at wrote:
> Am Mittwoch, 2. September 2015 schrieb Edward Bartolo:
>> Hi all,
>>
>> I think, I found an alternative to m
Am Mittwoch, 2. September 2015 schrieb Edward Bartolo:
> 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 con
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 importin
39 matches
Mail list logo
