proced: ppid of process ID 0 can be 0

proced: ppid of process ID 0 can be 0

[Juanma Barranquero]

proced.el assumes at several places (for example, at
`proced-filter-parents') that you can loop over the ppid, because
you'll eventually find a process with no parent.

That's not true with on Windows, where ppid (0) == 0. That causes a
stack failure, for example, if you hit RET (`proced-refine') over the
PPID of process 0.

I see two ways of fixing this: either removing the assumption from
proced.el, or forcing the Windows implementation of
system_process_attributes to adapt. First is more correct, second is
much easier (see tiny patch below).

Comments?

    Juanma


Index: src/w32.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32.c,v
retrieving revision 1.157
diff -u -2 -r1.157 w32.c
--- src/w32.c	19 Dec 2008 19:50:39 -0000	1.157
+++ src/w32.c	20 Dec 2008 02:34:39 -0000
@@ -3886,7 +3886,8 @@
 		}
 	      attrs = Fcons (Fcons (Qcomm, decoded_cmd), attrs);
-	      attrs = Fcons (Fcons (Qppid,
-				    make_fixnum_or_float (pe.th32ParentProcessID)),
-			     attrs);
+	      if (proc_id != 0)
+		attrs = Fcons (Fcons (Qppid,
+				      make_fixnum_or_float (pe.th32ParentProcessID)),
+			       attrs);
 	      attrs = Fcons (Fcons (Qpri, make_number (pe.pcPriClassBase)),
 			     attrs);

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

> +	      if (proc_id != 0)

Better test "proc_id != proc_id", I think.


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> +	      if (proc_id != 0)
>
> Better test "proc_id != proc_id", I think.

Wait, what?

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

>>> +	      if (proc_id != 0)
>> Better test "proc_id != proc_id", I think.
> Wait, what?

Damn, that thing was potent!


        Stef


PS: the intention was to compare the pid and the ppid.

Re: proced: ppid of process ID 0 can be 0

[Juanma Barranquero]

On Sat, Dec 20, 2008 at 04:27, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Better test "proc_id != proc_id", I think.

You mean to test proc_id != parent_id, like in the patch below?

That's OK too, although I don't think a process other than 0 can have
itself as parent.

    Juanma



Index: src/w32.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32.c,v
retrieving revision 1.157
diff -u -2 -r1.157 w32.c
--- src/w32.c	19 Dec 2008 19:50:39 -0000	1.157
+++ src/w32.c	20 Dec 2008 10:14:08 -0000
@@ -3886,7 +3886,8 @@
 		}
 	      attrs = Fcons (Fcons (Qcomm, decoded_cmd), attrs);
-	      attrs = Fcons (Fcons (Qppid,
-				    make_fixnum_or_float (pe.th32ParentProcessID)),
-			     attrs);
+	      if (proc_id != pe.th32ParentProcessID)
+		attrs = Fcons (Fcons (Qppid,
+				      make_fixnum_or_float (pe.th32ParentProcessID)),
+			       attrs);
 	      attrs = Fcons (Fcons (Qpri, make_number (pe.pcPriClassBase)),
 			     attrs);

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> Date: Sat, 20 Dec 2008 03:52:40 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> 
> proced.el assumes at several places (for example, at
> `proced-filter-parents') that you can loop over the ppid, because
> you'll eventually find a process with no parent.
> 
> That's not true with on Windows, where ppid (0) == 0. That causes a
> stack failure, for example, if you hit RET (`proced-refine') over the
> PPID of process 0.
> 
> I see two ways of fixing this: either removing the assumption from
> proced.el, or forcing the Windows implementation of
> system_process_attributes to adapt. First is more correct, second is
> much easier (see tiny patch below).

I'd prefer that proced.el doesn't make such an unportable assumption.
Roland?

Re: proced: ppid of process ID 0 can be 0

[Roland Winkler]

On Sat Dec 20 2008 Eli Zaretskii wrote:
> > I see two ways of fixing this: either removing the assumption from
> > proced.el, or forcing the Windows implementation of
> > system_process_attributes to adapt. First is more correct, second is
> > much easier (see tiny patch below).
> 
> I'd prefer that proced.el doesn't make such an unportable assumption.

I am not sure I get the point here. What is unportable where? I
mean, it seems to me that ultimately the solution is always the
same: when using the ppid attribute, one needs to make sure that it
is different from the corresponding pid. Or could one assign a
special meaning to the case that ppid=pid? There is no doubt that
proced assumes that ppid is always different from pid.

A comparison of ppid and pid can be implemented either on the level
of system_process_attributes. (I don't know whether for other
operating systems besides Windows we can have similar problems.) Or
it can be implemented inside proced. In the latter case, I would
implement the comparison of ppid and pid in
proced-process-attributes which is kind of the low-level function in
Proced calling system-process-attributes. (No other proced function
calls system-process-attributes.) So having the comparison of ppid
and pid in that function would work for proced for all operating
systems (requiring only a very small change in the code).

Yet anybody using system-process-attributes elsewhere might be
surprised that the return value of system-process-attributes can
give such meaningless results so that he/she probably would have to
implement the same check. So maybe for a clear definition of the
ppid attribute returned by system-process-attributes, we could
require that it must be different from pid.

Roland

Re: proced: ppid of process ID 0 can be 0

[Juanma Barranquero]

On Sat, Dec 20, 2008 at 20:41, Roland Winkler
<Roland.Winkler@physik.uni-erlangen.de> wrote:

> So maybe for a clear definition of the
> ppid attribute returned by system-process-attributes, we could
> require that it must be different from pid.

I agree.

If there were many platforms where ppid can be equal to pid, it would
make sense to generalize proced.el, but I don't think that's the case.

    Juanma

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> Date: Sat, 20 Dec 2008 20:41:20 +0100
> From: "Roland Winkler" <Roland.Winkler@physik.uni-erlangen.de>
> Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org
> 
> > I'd prefer that proced.el doesn't make such an unportable assumption.
> 
> I am not sure I get the point here. What is unportable where?

The assumption that going up the process tree will eventually find a
process that has no ppid attribute.

> I mean, it seems to me that ultimately the solution is always the
> same: when using the ppid attribute, one needs to make sure that it
> is different from the corresponding pid. Or could one assign a
> special meaning to the case that ppid=pid? There is no doubt that
> proced assumes that ppid is always different from pid.

Why do you need to assume that?  Is that only to determine whether a
given process is the root of the process tree?  If so, a more portable
way of doing that would be to have a primitive for that with a
system-dependent implementation.

If you need that assumption for something else, let's hear those other
reasons.

> Yet anybody using system-process-attributes elsewhere might be
> surprised that the return value of system-process-attributes can
> give such meaningless results

It is no more meaningless than having a process with no parent, IMO.

Re: proced: ppid of process ID 0 can be 0

[Roland Winkler]

On Sun Dec 21 2008 Eli Zaretskii wrote:
> > I mean, it seems to me that ultimately the solution is always the
> > same: when using the ppid attribute, one needs to make sure that it
> > is different from the corresponding pid. Or could one assign a
> > special meaning to the case that ppid=pid? There is no doubt that
> > proced assumes that ppid is always different from pid.
> 
> Why do you need to assume that?  Is that only to determine whether a
> given process is the root of the process tree?  If so, a more portable
> way of doing that would be to have a primitive for that with a
> system-dependent implementation.

It's the definition of a tree: when A points back to A, this doesn't
give a process tree. Of course, as I said, for Proced it is not so
important whether system-process-attributes can return a ppid that
equals pid or whether in this case it returns no ppid attribute
(or a ppid=0). It's easy to handle this case on te level of proced.

Yet the current discussion suggests to me that it would be
advantageous if the behavior of system-process-attributes was
documented for this case. It seems to me that the possiblities are:

- it may return a ppid that equals pid, so that one needs to handle
  this case appropriately, if necessary, on the lisp level,

- it may return no ppid, if strictly speaking there is no parent
  process

- it may return a ppid of zero, which is the current behavior under
  GNU/linux

- some or all the above options are "legal" and its up to the user
  to handle these possibilities appropriately

Is there any possiblity missing?

Roland

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> Date: Sat, 20 Dec 2008 23:41:00 +0100
> From: "Roland Winkler" <Roland.Winkler@physik.uni-erlangen.de>
> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> 
> On Sun Dec 21 2008 Eli Zaretskii wrote:
> > > I mean, it seems to me that ultimately the solution is always the
> > > same: when using the ppid attribute, one needs to make sure that it
> > > is different from the corresponding pid. Or could one assign a
> > > special meaning to the case that ppid=pid? There is no doubt that
> > > proced assumes that ppid is always different from pid.
> > 
> > Why do you need to assume that?  Is that only to determine whether a
> > given process is the root of the process tree?  If so, a more portable
> > way of doing that would be to have a primitive for that with a
> > system-dependent implementation.
> 
> It's the definition of a tree

Yes, but nobody said that looking at ppid you will have a proper tree.

> - it may return a ppid that equals pid, so that one needs to handle
>   this case appropriately, if necessary, on the lisp level,
> 
> - it may return no ppid, if strictly speaking there is no parent
>   process
> 
> - it may return a ppid of zero, which is the current behavior under
>   GNU/linux
> 
> - some or all the above options are "legal" and its up to the user
>   to handle these possibilities appropriately
> 
> Is there any possiblity missing?

Maybe not, but that's not what I was asking.  I was asking why you
need the assumption about this behavior.  I now understand that it is
only for handling processes as a tree.  So I will write a primitive
for the root of that tree that Lisp code should use for such
decisions.

Re: proced: ppid of process ID 0 can be 0

[Roland Winkler]

On Sun Dec 21 2008 Eli Zaretskii wrote:
> Yes, but nobody said that looking at ppid you will have a proper
> tree.

Under GNU/linux, the procps package contains not only the ps
command. But it also contains the command pstree. Though I didn't
look at pstree's source code, I guess it is doing its job by
analyzing ppid's.

Dan Nicolaescu had suggested ("wishlist") that it would be nice to
have an emacs/proced implementation of pstree. I guess he is right.
Often it might be much easier to manipulate processes if proced
didn't present the processes in some linear order; but instead it
made the tree structure with parents and children transparent.

> > Is there any possiblity missing?
> 
> Maybe not, but that's not what I was asking.  I was asking why you
> need the assumption about this behavior.  I now understand that it is
> only for handling processes as a tree.  So I will write a primitive
> for the root of that tree that Lisp code should use for such
> decisions.

Somehow I am missing the point here. Why do you think it is
necessary or advantageous to have a separate primitive for that?
Isn't it more transparent to implement this on the lisp level?

Proced already provides a function proced-process-tree. It seems to
me that all one needs for making this more robust is a more accurate
rule of how system-process-attributes handles the ppid attribute in
certain special cases. (And I expect that proced could easily work
around in a robust way if no such rule was implemented. Simply, up
to now I didn't worry about that when I wrote the proced code.)

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> Date: Sun, 21 Dec 2008 05:48:00 +0100
> From: "Roland Winkler" <Roland.Winkler@physik.uni-erlangen.de>
> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> 
> On Sun Dec 21 2008 Eli Zaretskii wrote:
> > Yes, but nobody said that looking at ppid you will have a proper
> > tree.
> 
> Under GNU/linux, the procps package contains not only the ps
> command. But it also contains the command pstree.

I don't see pstree in procps-3.2.7, perhaps I'm missing something.

> Though I didn't look at pstree's source code, I guess it is doing
> its job by analyzing ppid's.

I have no doubt that on GNU/Linux, a ppid of zero is a sign of the
root of the process tree.  But I wrote the 2 primitives that proced.el
uses in order to free proced.el of any such OS-dependent assumptions.
I have no problems with providing another one.

> Somehow I am missing the point here. Why do you think it is
> necessary or advantageous to have a separate primitive for that?

Because the implementation of such a predicate is inherently
OS-dependent, and I don't think proced.el (or any other Lisp program)
should know about how different OSes handle the root of their process
tree.

> Proced already provides a function proced-process-tree. It seems to
> me that all one needs for making this more robust is a more accurate
> rule of how system-process-attributes handles the ppid attribute in
> certain special cases.

A low-level primitive such as system-process-attributes should know
nothing about its users, ideally.  It should just return whatever the
OS tells it.  It should not adapt its handling of ppid to what its
callers might like or dislike.

> (And I expect that proced could easily work around in a robust way
> if no such rule was implemented. Simply, up to now I didn't worry
> about that when I wrote the proced code.)

I don't see how can you work around that without testing if you are on
windows-nt system or not.

Re: proced: ppid of process ID 0 can be 0

[Juanma Barranquero]

On Sun, Dec 21, 2008 at 20:17, Eli Zaretskii <eliz@gnu.org> wrote:

> A low-level primitive such as system-process-attributes should know
> nothing about its users, ideally.  It should just return whatever the
> OS tells it.  It should not adapt its handling of ppid to what its
> callers might like or dislike.

That is true. OTOH, your approach can also be evaluated by weighting
the complexity it introduces (however small) against the uncleanliness
of adapting one current primitive to cater to expectations. I'd be
more convinced that your generalization is useful if we had many
different platform-dependent implementations, but that does not seem
likely.

    Juanma

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> Date: Sun, 21 Dec 2008 22:26:15 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org, Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>
> 
> OTOH, your approach can also be evaluated by weighting the
> complexity it introduces (however small) against the uncleanliness
> of adapting one current primitive to cater to expectations.

I see no complexity at all.  Please tell what is complex about another
primitive.

Re: proced: ppid of process ID 0 can be 0

[Juanma Barranquero]

On Mon, Dec 22, 2008 at 05:09, Eli Zaretskii <eliz@gnu.org> wrote:

> I see no complexity at all.  Please tell what is complex about another
> primitive.

Lines of code, for starters. And the need to document it, even if only
in a comment or a docstring.

Which is much more worthwhile if the primitive is generally useful.

    Juanma

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> Date: Mon, 22 Dec 2008 11:41:22 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org, Roland.Winkler@physik.uni-erlangen.de
> 
> Which is much more worthwhile if the primitive is generally useful.

Judging by the latest posts, there seems to be at least one more OS
where the Linux logic will not work, unless I'm mistaken.

Re: proced: ppid of process ID 0 can be 0

[Juanma Barranquero]

> Judging by the latest posts, there seems to be at least one more OS
> where the Linux logic will not work, unless I'm mistaken.

Apparently so, yes.

Well, IMHO the situation does not merit introducing a primitive for
it, but of course I'm not going to oppose it, either. In fact, looking
for a function to find the root of a process tree was the reason I
discovered the problem in proced in the first place...

    Juanma

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

> I have no doubt that on GNU/Linux, a ppid of zero is a sign of the
> root of the process tree.  But I wrote the 2 primitives that proced.el
> uses in order to free proced.el of any such OS-dependent assumptions.
> I have no problems with providing another one.

The primitives should ensure that what they return forms a forest.
I.e. under POSIX, they should treat a "ppid == 0" as meaning that
there's no parent (i.e. the data returned to Elisp should never say "the
parent is process 0" but should instead say "this process doesn't have
a parent").


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>,  lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 21 Dec 2008 21:45:06 -0500
> 
> The primitives should ensure that what they return forms a forest.

You mean a tree.

> I.e. under POSIX, they should treat a "ppid == 0" as meaning that
> there's no parent (i.e. the data returned to Elisp should never say "the
> parent is process 0" but should instead say "this process doesn't have
> a parent").

For me, code that calls process-tree-root-p (say) is much more
self-explanatory than a test for a missing parent pid attribute.  It
is also more reliable, since ppid attribute could be missing for some
other reason, like failure to access the attribute.

So I don't understand why you insist on the above, please feel free to
explain what advantages do you see there.

Btw, is the above really mandated by Posix?  Any references to that?

Re: proced: ppid of process ID 0 can be 0

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> So I don't understand why you insist on the above, please feel free to
> explain what advantages do you see there.

More elegant, less confusing than a "magic" value for the ppid.

-Miles

-- 
I'd rather be consing.

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Mon, 22 Dec 2008 13:17:15 +0900
> Cc: lekktu@gmail.com, Roland.Winkler@physik.uni-erlangen.de,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > So I don't understand why you insist on the above, please feel free to
> > explain what advantages do you see there.
> 
> More elegant, less confusing than a "magic" value for the ppid.

But I wasn't suggesting to use magic values.  You confused me with
someone else.  I was suggesting a primitive, so that Lisp code will
be oblivious as to how tree root is determined.

Re: proced: ppid of process ID 0 can be 0

[Harald Hanche-Olsen]

+ Eli Zaretskii <eliz@gnu.org>:

>> I.e. under POSIX, they should treat a "ppid == 0" as meaning that
>> there's no parent (i.e. the data returned to Elisp should never say "the
>> parent is process 0" but should instead say "this process doesn't have
>> a parent").
> 
> [...]
> 
> Btw, is the above really mandated by Posix?  Any references to that?

FWIW, on FreeBSD there is process 0 (the swapper), and various kernel
processes have process 0 as their parent.

; pstree 0
-+= 00000 root [swapper]
 |-+= 00001 root /sbin/init --
 | |--= 00354 _dhcp dhclient: em0 (dhclient)
 | |--= 00623 root /sbin/devd
.... <snip> ....
 |--- 00002 root [g_event]
 |--- 00003 root [g_up]
 |--- 00004 root [g_down]
 |--- 00005 root [system_taskq]
 |--- 00006 root [system_taskq]
 |--- 00007 root [acpi_task_0]
.... <snipetty snip> ....

Of course, it may be that you really don't want emacs to see kernel
processes at all.

- Harald

Re: proced: ppid of process ID 0 can be 0

[Juanma Barranquero]

On Mon, Dec 22, 2008 at 09:54, Harald Hanche-Olsen <hanche@math.ntnu.no> wrote:

> FWIW, on FreeBSD there is process 0 (the swapper), and various kernel
> processes have process 0 as their parent.

There's no problem with a process having ppid = 0. But there's a
problem with processes having ppid = pid. Is that the case in FreeBSD?

    Juanma

Re: proced: ppid of process ID 0 can be 0

[Harald Hanche-Olsen]

+ "Juanma Barranquero" <lekktu@gmail.com>:

> There's no problem with a process having ppid = 0. But there's a
> problem with processes having ppid = pid. Is that the case in FreeBSD?

Apparently it is:

; ps -o pid,ppid,command 0
  PID  PPID COMMAND
    0     0 [swapper]

- Harald

Re: proced: ppid of process ID 0 can be 0

[Giorgos Keramidas]

On Mon, 22 Dec 2008 11:43:15 +0100, "Juanma Barranquero" <lekktu@gmail.com> wrote:
> On Mon, Dec 22, 2008 at 09:54, Harald Hanche-Olsen <hanche@math.ntnu.no> wrote:
>
>> FWIW, on FreeBSD there is process 0 (the swapper), and various kernel
>> processes have process 0 as their parent.
>
> There's no problem with a process having ppid = 0. But there's a
> problem with processes having ppid = pid. Is that the case in FreeBSD?

Yes this is the case:

$ ps -xao pid,ppid,args | sed -n -e 1p -e /sed/d -e /kernel/p
  PID  PPID COMMAND
    0     0 [kernel]
$

There are several processes with ppid == 0, and process 0 has pid == ppid:

  PID  PPID COMMAND
    0     0 [kernel]
    1     0 /sbin/init --
    2     0 [g_event]
    3     0 [g_up]
    4     0 [g_down]
    5     0 [xpt_thrd]
    6     0 [sctp_iterator]
    7     0 [pfpurge]
    8     0 [pagedaemon]
    9     0 [vmdaemon]
   10     0 [audit]
   11     0 [idle]
   12     0 [intr]
   13     0 [yarrow]
   14     0 [usb0]
   15     0 [usbtask-hc]
   16     0 [usbtask-dr]
   17     0 [usb1]
   18     0 [usb2]
   19     0 [usb3]
   20     0 [usb4]
   21     0 [usb5]
   22     0 [usb6]
   23     0 [acpi_thermal]
   24     0 [acpi_cooling0]
   25     0 [pagezero]
   26     0 [bufdaemon]
   27     0 [vnlru]
   28     0 [syncer]
   29     0 [softdepflush]
 1019     0 [md0]

Re: proced: ppid of process ID 0 can be 0

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>,  lekktu@gmail.com,  emacs-devel@gnu.org
>> Date: Sun, 21 Dec 2008 21:45:06 -0500
>> 
>> The primitives should ensure that what they return forms a forest.
>
> You mean a tree.

There are at least two process trees in modern Linux: one tree rooted at
init (pid 1) and another one rooted at kthreadd (the mother of all
kernel threads).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, lekktu@gmail.com,
> 	emacs-devel@gnu.org, Roland.Winkler@physik.uni-erlangen.de
> Date: Mon, 22 Dec 2008 11:59:37 +0100
> 
> There are at least two process trees in modern Linux: one tree rooted at
> init (pid 1) and another one rooted at kthreadd (the mother of all
> kernel threads).

On this system:

   Linux fencepost 2.6.16.29-xen #1 SMP Wed Dec 6 07:32:36 EST 2006 x86_64 GNU/Linux

I don't see a kthreadd process.  I only see a kthread (one d) which is
a child of init.  Is this because this system is not modern enough?

Re: proced: ppid of process ID 0 can be 0

[David De La Harpe Golden]

Eli Zaretskii wrote:

> I don't see a kthreadd process.  I only see a kthread (one d) which is
> a child of init.  Is this because this system is not modern enough?
> 
> 

On my 2.6.26 system, I have an init (pid 1, ppid 0) and a
[kthreadd] (pid 2, ppid 0), according to ps ajx

Re: proced: ppid of process ID 0 can be 0

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> On this system:
>
>    Linux fencepost 2.6.16.29-xen #1 SMP Wed Dec 6 07:32:36 EST 2006 x86_64 GNU/Linux
>
> I don't see a kthreadd process.

It was added in v2.6.22-rc1 (1½ years ago).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

>> The primitives should ensure that what they return forms a forest.
> You mean a tree.

No, I meant a forest.  It may consist of a single tree, but I see no
reason to impose such a constraint.

>> I.e. under POSIX, they should treat a "ppid == 0" as meaning that
>> there's no parent (i.e. the data returned to Elisp should never say "the
>> parent is process 0" but should instead say "this process doesn't have
>> a parent").

> For me, code that calls process-tree-root-p (say) is much more
> self-explanatory than a test for a missing parent pid attribute.

To me the definition of "root" is "has no parent", so the two are
equivalent.  I could live with a predicate process-tree-root-p, but I'd
expect it to just check for the absence of a parent.

> It is also more reliable, since ppid attribute could be missing for
> some other reason, like failure to access the attribute.

And what would your process-tree-root-p say in that case?

> Btw, is the above really mandated by Posix?  Any references to that?

I don't know, but whatever it is POSIX say, it should be handled in the
POSIX implementation of system-process-attributes.
On my GNU/Linux system, 0 is not a process, so a ppid of 0 is not
a parent but rather the mark of the absence of a parent.


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de,  lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 22 Dec 2008 07:23:05 -0500
> 
> To me the definition of "root" is "has no parent", so the two are
> equivalent.

Same here.  But "having no parent" and "found zero in /proc/NNN/stat"
is not necessarily the same.

> I could live with a predicate process-tree-root-p, but I'd expect it
> to just check for the absence of a parent.

Me too.  However, that check is OS-dependent, so I don't think it
should be in Lisp.

> > It is also more reliable, since ppid attribute could be missing for
> > some other reason, like failure to access the attribute.
> 
> And what would your process-tree-root-p say in that case?

It depends on the OS.

> On my GNU/Linux system, 0 is not a process, so a ppid of 0 is not
> a parent but rather the mark of the absence of a parent.

Sounds like this isn't true on FreeBSD as well, not only on
MS-Windows.

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

>> To me the definition of "root" is "has no parent", so the two are
>> equivalent.
> Same here.  But "having no parent" and "found zero in /proc/NNN/stat"
> is not necessarily the same.
>> I could live with a predicate process-tree-root-p, but I'd expect it
>> to just check for the absence of a parent.
> Me too.  However, that check is OS-dependent, so I don't think it
> should be in Lisp.

Indeed, it should be in system-process-attributes which is already
OS-dependent.


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de,  lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 22 Dec 2008 17:24:24 -0500
> 
> >> To me the definition of "root" is "has no parent", so the two are
> >> equivalent.
> > Same here.  But "having no parent" and "found zero in /proc/NNN/stat"
> > is not necessarily the same.
> >> I could live with a predicate process-tree-root-p, but I'd expect it
> >> to just check for the absence of a parent.
> > Me too.  However, that check is OS-dependent, so I don't think it
> > should be in Lisp.
> 
> Indeed, it should be in system-process-attributes which is already
> OS-dependent.

If you mean by having no ppid attribute, then that's ambiguous, since
an attribute can be missing because it is inaccessible for some
reason, like some kind of failure unrelated to the fact that the
process is really a root of a tree.

Re: proced: ppid of process ID 0 can be 0

[Roland Winkler]

> > Indeed, it should be in system-process-attributes which is already
> > OS-dependent.
> 
> If you mean by having no ppid attribute, then that's ambiguous, since
> an attribute can be missing because it is inaccessible for some
> reason, like some kind of failure unrelated to the fact that the
> process is really a root of a tree.

I was offline for a few days. In my humble opinion, the behavior of
pstree is really exactly what I would find useful from a practical
point of view. Pstree's man page says:

  pstree shows running processes as a tree. The tree is rooted at
  either pid or init if pid is omitted. If a user name is specified,
  all process trees rooted at processes owned by that user are
  shown.

Unless I am overlooking something, this means that within a list of
processes (say, the processes owned by $USER or root), *a* root is a
process that doesn't have a parent process within the given list of
processes. This implies that one can get several distinct process
trees from one list of processes. For example, on my GNU/linux system:

- For `pstree 1', the process tree starts with init.

- `pstree 2' shows kthreadd and its children

- Both root and kthreadd have ppid 0. But `pstree 0' gives an error.

- `pstree $USER' gives many unrelated trees, that is, for pstree
  there is generally no such thing like `the' root of `the' process
  tree.

- `pstree root' seems to be a minor inconsistency as it is
  equivalent to `pstree 1'. It seems to ignore the process tree
  rooted in kthreadd.

All this behavior is currently implemented in proced-process-tree
with the only bug that it yields an infinite recursion if
according to system-process-attributes a process is its own parent.
(I guess it is fine that system-process-attributes always reports
the ppid it gets from the OS. An application like proced can handle
such special cases easily.)

Having read the recent contributions to this thread I do not see why
anything more sophisticated could be useful. For all useful
scenarios I can envision, the ppid attribute of
system-process-attributes is all that is needed. To consider process
B the child of process A it is necessary that B has the ppid
attribute with a value that is the pid of A. Any other case (ppid
attribute absent, having a value that points to a nonexistent
process or whatever) doesn't allow one to put A and B one above each
other in a process tree, so it seems to me that it's not worth the
effort to worry about the details in emacs.

Though I didn't read the code of pstree in detail, I'd be very
surprised if it used a more sophisticated scheme.

Roland

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

>> Indeed, it should be in system-process-attributes which is already
>> OS-dependent.
> If you mean by having no ppid attribute, then that's ambiguous, since
> an attribute can be missing because it is inaccessible for some
> reason, like some kind of failure unrelated to the fact that the
> process is really a root of a tree.

Seems very hypothetical.  And on top of that, even in that hypothetical
case, it's far from clear that it would create any problem.  More to the
point: even if we could distinguish the "no ppid" from "unkown ppid",
it's unclear how Elisp code could make use of it.  So I think we
shouldn't worry about it.


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de,  lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 23 Dec 2008 09:44:29 -0500
> 
> >> Indeed, it should be in system-process-attributes which is already
> >> OS-dependent.
> > If you mean by having no ppid attribute, then that's ambiguous, since
> > an attribute can be missing because it is inaccessible for some
> > reason, like some kind of failure unrelated to the fact that the
> > process is really a root of a tree.
> 
> Seems very hypothetical.

It's not hypothetical, I've seen such cases and reported them to
Roland.

> More to the point: even if we could distinguish the "no ppid" from
> "unkown ppid", it's unclear how Elisp code could make use of it.

Lisp code cannot, but a primitive written in C can.

But we are repeating ourselves.

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

>> >> Indeed, it should be in system-process-attributes which is already
>> >> OS-dependent.
>> > If you mean by having no ppid attribute, then that's ambiguous, since
>> > an attribute can be missing because it is inaccessible for some
>> > reason, like some kind of failure unrelated to the fact that the
>> > process is really a root of a tree.
>> Seems very hypothetical.
> It's not hypothetical, I've seen such cases and reported them to
> Roland.

What were those cases?

>> More to the point: even if we could distinguish the "no ppid" from
>> "unkown ppid", it's unclear how Elisp code could make use of it.
> Lisp code cannot, but a primitive written in C can.

Like what can it do?


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Giorgos Keramidas]

On Tue, 23 Dec 2008 15:41:56 -0500, Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:
>>> >> Indeed, it should be in system-process-attributes which is already
>>> >> OS-dependent.
>>> > If you mean by having no ppid attribute, then that's ambiguous, since
>>> > an attribute can be missing because it is inaccessible for some
>>> > reason, like some kind of failure unrelated to the fact that the
>>> > process is really a root of a tree.
>>>
>>> Seems very hypothetical.
>>
>> It's not hypothetical, I've seen such cases and reported them to
>> Roland.
>
> What were those cases?
>
>>> More to the point: even if we could distinguish the "no ppid" from
>>> "unkown ppid", it's unclear how Elisp code could make use of it.
>> Lisp code cannot, but a primitive written in C can.
>
> Like what can it do?

It can differentiate between FreeBSD 4.3 and FreeBSD 7.2 if they use a
different style of `process root', or between Linux 1.2.X, 2.4.X and
2.6.X.  Right now, Emacs sets `system-type' to "berkeley-unix" on more
than one BSD system.  They might be easier to detect at C level.

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

>>>> More to the point: even if we could distinguish the "no ppid" from
>>>> "unkown ppid", it's unclear how Elisp code could make use of it.
>>> Lisp code cannot, but a primitive written in C can.
>> 
>> Like what can it do?

> It can differentiate between FreeBSD 4.3 and FreeBSD 7.2 if they use a
> different style of `process root', or between Linux 1.2.X, 2.4.X and
> 2.6.X.  Right now, Emacs sets `system-type' to "berkeley-unix" on more
> than one BSD system.  They might be easier to detect at C level.

That's not what I'm asking.  I'm asking: what can C code (or Elisp code
for that matter) do when the ppid is somehow not found (i.e. there's no
ppid available, but the process might have a parent).


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  lekktu@gmail.com,  emacs-devel@gnu.org,  Roland.Winkler@physik.uni-erlangen.de
> Date: Tue, 23 Dec 2008 21:34:56 -0500
> 
> >>>> More to the point: even if we could distinguish the "no ppid" from
> >>>> "unkown ppid", it's unclear how Elisp code could make use of it.
> >>> Lisp code cannot, but a primitive written in C can.
> >> 
> >> Like what can it do?
> 
> > It can differentiate between FreeBSD 4.3 and FreeBSD 7.2 if they use a
> > different style of `process root', or between Linux 1.2.X, 2.4.X and
> > 2.6.X.  Right now, Emacs sets `system-type' to "berkeley-unix" on more
> > than one BSD system.  They might be easier to detect at C level.
> 
> That's not what I'm asking.  I'm asking: what can C code (or Elisp code
> for that matter) do when the ppid is somehow not found (i.e. there's no
> ppid available, but the process might have a parent).

The process-tree-root-p primitive does not need to employ the same
logic (nor even the same syscalls, actually) that
system-process-attributes does.  The latter simply omits from the
alist it returns any attribute that it could not fetch for some
reason, any reason.  The former could do something else.  What
exactly, I will figure out when I write it.

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

> The process-tree-root-p primitive does not need to employ the same
> logic (nor even the same syscalls, actually) that
> system-process-attributes does.  The latter simply omits from the
> alist it returns any attribute that it could not fetch for some
> reason, any reason.  The former could do something else.  What
> exactly, I will figure out when I write it.

So you're saying that by working hard you can maybe in some corner case
give a more precise answer for the boolean `process-tree-root-p' while
the parent process is not returned by `system-process-attributes'.
I can't think of any situation where process-tree-root-p would be useful
and where the ppids wouldn't be needed.

I also still have no idea how/when system-process-attributes could fail
to return ppids.

It still sounds terribly far fetched.


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Roland.Winkler@physik.uni-erlangen.de, lekktu@gmail.com,
>         emacs-devel@gnu.org
> Date: Tue, 23 Dec 2008 15:41:56 -0500
> 
> >> >> Indeed, it should be in system-process-attributes which is already
> >> >> OS-dependent.
> >> > If you mean by having no ppid attribute, then that's ambiguous, since
> >> > an attribute can be missing because it is inaccessible for some
> >> > reason, like some kind of failure unrelated to the fact that the
> >> > process is really a root of a tree.
> >> Seems very hypothetical.
> > It's not hypothetical, I've seen such cases and reported them to
> > Roland.
> 
> What were those cases?

Processes that disappeared while Emacs was reading /proc, for example.

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

>> > It's not hypothetical, I've seen such cases and reported them to
>> > Roland.
>> What were those cases?
> Processes that disappeared while Emacs was reading /proc, for example.

Then don't return them at all rather than returning them with
incomplete data.


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de,  lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 24 Dec 2008 11:47:12 -0500
> 
> >> > It's not hypothetical, I've seen such cases and reported them to
> >> > Roland.
> >> What were those cases?
> > Processes that disappeared while Emacs was reading /proc, for example.
> 
> Then don't return them at all

How?  I don't know enough about Linux kernel internals to decide which
attribute's absence means that the process died while Emacs was
reading /proc.  For examples, quite a few lack the command line, but I
don't think that's a good reason to not return such processes.  In
addition, judging by comments in procps sources, the set of attributes
depend on the version of the Linux kernel.  If you (or someone else)
can define a clear logic, one that won't change with the next release
of the kernel, then perhaps we could avoid returning such processes.

Reading /proc is inherently prone to race conditions with the kernel,
unless someone can suggest a way of getting from /proc a consistent
snapshot of the set of system processes.  I don't see how to overcome
this difficulty at the primitive level.

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

>> > Processes that disappeared while Emacs was reading /proc, for example.
>> Then don't return them at all
> How?  I don't know enough about Linux kernel internals to decide which
> attribute's absence means that the process died while Emacs was
> reading /proc.

AFAIK we're talking about ppid, and this info is always present, so if
it's absent, don't return the process.


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de,  lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 24 Dec 2008 13:55:51 -0500
> 
> >> > Processes that disappeared while Emacs was reading /proc, for example.
> >> Then don't return them at all
> > How?  I don't know enough about Linux kernel internals to decide which
> > attribute's absence means that the process died while Emacs was
> > reading /proc.
> 
> AFAIK we're talking about ppid, and this info is always present, so if
> it's absent, don't return the process.

Can you find any authoritative reference that says we can rely on
this?  I couldn't even find a decent documentation of /proc when I was
working on these primitives, let alone some information about what
attributes are always present or how that changes with the kernel
version.

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

>> >> > Processes that disappeared while Emacs was reading /proc, for example.
>> >> Then don't return them at all
>> > How?  I don't know enough about Linux kernel internals to decide which
>> > attribute's absence means that the process died while Emacs was
>> > reading /proc.
>> 
>> AFAIK we're talking about ppid, and this info is always present, so if
>> it's absent, don't return the process.

> Can you find any authoritative reference that says we can rely on
> this?  I couldn't even find a decent documentation of /proc when I was
> working on these primitives, let alone some information about what
> attributes are always present or how that changes with the kernel
> version.

The ppid is in the /proc/NNN/stat file, those attributes are
distinguished by their order, so if it's missing the ordering gets
messed up, so it can't be missing.  As for the /proc/NNN/stat file
missing, that would mean that pretty much all the attributes returned by
`ps' would be missing, so we can definitely count on its presence.


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Roland.Winkler@physik.uni-erlangen.de,  lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 30 Dec 2008 12:11:15 -0500
> 
> >> AFAIK we're talking about ppid, and this info is always present, so if
> >> it's absent, don't return the process.
> 
> > Can you find any authoritative reference that says we can rely on
> > this?  I couldn't even find a decent documentation of /proc when I was
> > working on these primitives, let alone some information about what
> > attributes are always present or how that changes with the kernel
> > version.
> 
> The ppid is in the /proc/NNN/stat file, those attributes are
> distinguished by their order, so if it's missing the ordering gets
> messed up, so it can't be missing.  As for the /proc/NNN/stat file
> missing, that would mean that pretty much all the attributes returned by
> `ps' would be missing, so we can definitely count on its presence.

Sorry, this doesn't even come close to being an "authoritative
reference".  These are just deliberations based on some concept of how
/proc is implemented in the Linux kernel, and I have no idea how close
is this concept to the truth.

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

> Sorry, this doesn't even come close to being an "authoritative
> reference".  These are just deliberations based on some concept of how
> /proc is implemented in the Linux kernel, and I have no idea how close
> is this concept to the truth.

No, this is not based on any details of how it's implemented in
the kernel.  It's based on how the info is provided to the user
processes.  I'm pretty sure if you look at it, you'll come to the
same conclusion.


        Stefan

Re: proced: ppid of process ID 0 can be 0

[Ulrich Mueller]

>>>>> On Sun, 21 Dec 2008, Eli Zaretskii wrote:

>> Under GNU/linux, the procps package contains not only the ps
>> command. But it also contains the command pstree.

> I don't see pstree in procps-3.2.7, perhaps I'm missing something.

You aren't. pstree is part of the psmisc package.
<http://psmisc.sourceforge.net/>

>> Though I didn't look at pstree's source code, I guess it is doing
>> its job by analyzing ppid's.

It does.

Ulrich

Re: proced: ppid of process ID 0 can be 0

[Stefan Monnier]

>> > I'd prefer that proced.el doesn't make such an unportable assumption.
>> I am not sure I get the point here. What is unportable where?

> The assumption that going up the process tree will eventually find a
> process that has no ppid attribute.

I think it's a fine assumption.  It is basically the same as saying that
the processes form a tree (or a forest), which is generally true, AFAIK.


        Stefan

Re: proced: ppid of process ID 0 can be 0

[grischka]

> That's not what I'm asking.  I'm asking: what can C code (or 
> Elisp code or that matter) do when the ppid is somehow not 
> found (i.e. there's no ppid available, but the process might 
> have a parent).

Well, for example:

(when 
  (although
   (maybe-not (process-tree-root-p pid))
   (somehow-not-found-p (process-parent pid))
   )
  (with the-thing
    (begin-to-believe 
       (if (y-or-n-p "Continue? ") 'funny 'strange)
       )))