API: Process names, arguments and executables
Floris Bruynooghe
As Chris noticed getting the name of a process is very complicated
right now and requires a lot of platforms specific knowledge. So here
a proposal for sorting this out.
Currently we have a number of attributes:
Process.argc
Process.args
Process.accounting_name
Process.command
Process.exe
P.argc is always filled in, this is simple.
P.args is not filled in on Solaris when you don't have permission or in
case of kernel LWPs where it simply doesn't exist. Otherwise it is
always present AFAIK.
P.accounting_name gets the name from /proc/pid/stat on Linux, on
OSX it seems to get kp_proc.p_comm which is not used anywhere
else. On Solaris and AIX it's simply left at NotImplemented
currently.
P.command is set to (a possibly incomplete) string of the entire
command line. On most systems this is just ' '.join(p.args) but on
Solaris it's not always complete. On Linux this is an empty string
for kernel processes.
And finally P.exe is normally an absolute path to the executable, but
sometimes only the basename. On Linux it's also possible for this to
be completely missing in case of a kernel thread.
I think p.argc, p.args and p.exe already have pretty easily
predictable names and behaviours. (So does p.command but see below)
So my proposal is to change p.accounting_name into a shorter p.name
attribute and make it mandatory for all implementations to define it.
It should be the accounting name if that exists, otherwise the
basename of the executable. If this is missing too (currently not
possible AFAIK) it should fall back to the basename of the p.args[0] (or
equivalent extracted from p.command).
Secondly I think it would be nice to have p.command always set to the
most meaningful value. It's already pretty good but on Linux you can
end up with an empty sting. I think it would be nice in that case to
set it to p.name (without the squre brackets mentioned below). This
should be done in src/process.c and not in arch implementations I
reckon, arch implementations are obliged to fill it in as now, even if
it's an empty string.
Finally I would consider putting the value of p.name in square
brackets if it's a kernel thread, like done in ps. This is slightly
obsolte since you can detect a kernel thread from a missing p.exe. On
the other hand the reverse is true too and you can strip the square
brackets if there's no p.exe. This is mostly a case of deciding what
the most common case is, and I'm tempted to go with square brackets
being disirable usually. This can be entrirely implemented in the
common code of src/process.c so no implementation code is required
anyway.
In summary this would make p.argc, p.name and p.command always present
and meaningful. And that's pretty good coverage for simply getting as
much useful information to the user reliably.
Any feedback? I will create a wiki page explaining this when we agree
on a policy for this stuff.
Cheers
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
Chris Miles
Anything that improves this situation gets my vote :-)
I like the idea of p.name always trying to present a usable name. That
would help people a lot.
>
> Secondly I think it would be nice to have p.command always set to the
> most meaningful value. It's already pretty good but on Linux you can
> end up with an empty sting. I think it would be nice in that case to
> set it to p.name (without the squre brackets mentioned below). This
> should be done in src/process.c and not in arch implementations I
> reckon, arch implementations are obliged to fill it in as now, even if
> it's an empty string.
Ok. I can't picture how this will look in all cases but am happy to
see it in action.
>
> Finally I would consider putting the value of p.name in square
> brackets if it's a kernel thread, like done in ps. This is slightly
> obsolte since you can detect a kernel thread from a missing p.exe. On
> the other hand the reverse is true too and you can strip the square
> brackets if there's no p.exe. This is mostly a case of deciding what
> the most common case is, and I'm tempted to go with square brackets
> being disirable usually. This can be entrirely implemented in the
> common code of src/process.c so no implementation code is required
> anyway.
I'm not too convinced about the square brackets. Isn't this just a
Linux kernel convention? I don't notice it anywhere else.
A "kernel_thread" boolean attribute would be useful, if we are easily
able to determine which "processes" are actually kernel threads. Is
this possible (and applicable) on all platforms?
If square brackets is Linux kernel specific, then I wouldn't mind that
convention used on Linux only.
>
> In summary this would make p.argc, p.name and p.command always present
> and meaningful. And that's pretty good coverage for simply getting as
> much useful information to the user reliably.
Agreed.
Cheers
Chris
Floris Bruynooghe
> On 01/08/2009, at 8:44 AM, Floris Bruynooghe wrote:
> > Finally I would consider putting the value of p.name in square
> > brackets if it's a kernel thread, like done in ps. This is slightly
> > obsolte since you can detect a kernel thread from a missing p.exe. On
> > the other hand the reverse is true too and you can strip the square
> > brackets if there's no p.exe. This is mostly a case of deciding what
> > the most common case is, and I'm tempted to go with square brackets
> > being disirable usually. This can be entrirely implemented in the
> > common code of src/process.c so no implementation code is required
> > anyway.
>
> I'm not too convinced about the square brackets. Isn't this just a
> Linux kernel convention? I don't notice it anywhere else.
Fine, let's not do that.
> A "kernel_thread" boolean attribute would be useful, if we are easily
> able to determine which "processes" are actually kernel threads. Is
> this possible (and applicable) on all platforms?
I'm not confident that we could do this properly. But the heuristic
is a process with no .exe attribute I reckon (.exe is obligatory
otherwise). And in that case adding an attribute seems redundant.
> If square brackets is Linux kernel specific, then I wouldn't mind that
> convention used on Linux only.
Hum, let's not do it anywhere then.
I think when this and the .cwd attribute on Darwin are done we should
do an other beta release. Having said that I'm just about to
disappear for two weeks on holiday, so I'd guess it would tentatively
be for the 2nd half of September.
Regards
Floris Bruynooghe
I've finally got round to updating psi to follow what's discussed
here, for a more readable version of what's finally been implemented
after the discussion I've documented it on the wiki too:
http://bitbucket.org/chrismiles/psi/wiki/ProcArgsExe
Note that once more I haven't compiled or tested the Darwin port, so
if someone could check that one does indeed the correct thing that
would be great.
Personally I think everything is feature complete for the next
release, with APIs that have unfortunately changed but should be more
future proof now. So I try to build and run on all the platforms and
python versions I have in the next few weeks and if nothing comes up
then make the next release.
Still missing is Process.cwd for Darwin, but I don't feel like
blocking the release for this. I am tempted however to make the test
fail (currently I expects an exception on Darwin) so that it's more in
your face. :-)
Regards
Floris
Chris Miles
That sounds fair. I had put my hand up for Process.cwd but since then
too many other priorities have got in the way.
I'll try and test on Darwin at least (can test on Snow Leopard now) if
nobody else beats me to it. Feel free to bug me if the lack of Darwin
testing holds a release up.
Cheers,
Chris