[Toybox] Fwd: [PATCH] Show thread names with "ps -T" on Android.

[Rob Landley]

On 09/29/2016 03:11 PM, enh wrote:
> On Thu, Sep 29, 2016 at 12:03 PM, Rob Landley <rob at landley.net> wrote:
>>> (i noticed
>>> as well that the GNU ps docs claim that -123 should work the same as
>>> 123,
>>
>> Um, but the comment on the new code hunk says it's undocumented?
> 
> yeah, that could have been clearer too. i meant "not in the help
> output [afaics]". but i did find it in the man page:
> 
> PROCESS SELECTION BY LIST
>        These options accept a single argument in the form of a blank-separated
>        or comma-separated list.  They can be used multiple times.  For
>        example: ps -p "1 2" -p 3,4
> 
>        -123   Identical to --pid 123.
> 
>        123    Identical to --pid 123.
> 
> but like i said, -123 doesn't work for me on ubuntu 14.04. (plus it
> seems insane.)

Yeah, skipping the first '-' of each leftover argument's easy enough,
but to _get_ them I have to add "?" to the optstr to allow unknown
arguments through, which means I need to do my own error handling for -B
and similar, and _that_ probably puts it over the threshold into "not
worth doing".

>> Where is this?
>>
>>> but that doesn't seem to be true in practice,
>>
>> landley at driftwood:~/toybox/toy3$ ps -24000
>>   PID TTY      STAT   TIME COMMAND
>> 24000 pts/100  Ss     0:00 bash
>> landley at driftwood:~/toybox/toy3$ ps 24000
>>   PID TTY      STAT   TIME COMMAND
>> 24000 pts/100  Ss     0:00 bash
>>
>> Seems to work?
> 
> /me really needs to be more specific... when i said "doesn't work" i
> meant "isn't reasonable":
> 
> ~$ ps 1 123
>   PID TTY      STAT   TIME COMMAND
>     1 ?        Ss     7:07 /sbin/init
>   123 ?        S      0:00 [rcuos/114]
> ~$ ps -1 -123
>   PID TTY      STAT   TIME COMMAND
>     1 ?        Ss     7:07 /sbin/init
> ~$

I think this goes into "don't do it and wait for somebody to complain
presenting an actual use case" territory. :)

I checked busybox ps really quick to see that that's doing, and "ps",
"ps ax", "ps 42", and "ps walrus" all gave the exact same output. :)

(Strangely, it accepts/ignores ps -a, but ps -x gives an error and usage
message. Huh.)

I feel pretty good not supporting ps -123 for now. :)

>> $ ps -p 32226,-32589
>> error: process ID out of range
> 
> that was the point at which i gave up and said "YAGNI".
> 
> see also:
> 
> ~$ ps -p 1 -p 123 124
>   PID TTY      STAT   TIME COMMAND
>     1 ?        Ss     7:07 /sbin/init
>   123 ?        S      0:00 [rcuos/114]
>   124 ?        S      0:00 [rcuos/115]
> 
> versus
> 
> ~$ ps -p 1 -p 123 -124
>   PID TTY      STAT   TIME COMMAND
>     1 ?        Ss     7:07 /sbin/init
>   123 ?        S      0:00 [rcuos/114]
> 
> -PID is utterly broken. i don't think -PID works well enough for
> anyone to be using it.

I need to make another stab at doing a test suite for this, which will
probably involve having a static snapshot of /proc --bind mounted over
it for the duration of the test. (Otherwise kernel threads butterfly
effect the test results no matter how tightly I try to constrain an
emulated test environment.)

> i'm not even sure what "sane" would look like, especially with things
> like abs(MIN_INT)... if we wait until someone actually needs -PID
> we'll have a better idea of what it should actually do.

For kill -pid means process groups. From the man page:

  Negative PID values may be  used  to  choose  whole
  process  groups; see the PGID column in ps command output.
  A PID of -1 is special; it indicates all processes except the
  kill  process  itself and init.

IF I was going to implement negative pid support here, I'd lean towards
that. But for now, it remains an if.

>> Rob
>>
>> P.S. Can I cc: this back to the list? :)
> 
> sure.
> 

Done.

Rob