Re: [9fans] ps bug

[Prof Brucee]

It's taken nearly 3 days for Ubuntu to upgrade (vmware) with kswapd using
more than 100 mins of CPU.

8 3.8GHz procs. Deeply wrong.

brucee

On 12/04/2017 1:32 PM, "Winston Kodogo"  wrote:

There is something deeply wrong with many things. Just ask jwz:

https://www.jwz.org/blog/2017/04/would-you-like-to-
supersize-that-for-a-dollar-extra/

But at least ed is still the standard editor. Such is progress.

On 12 April 2017 at 15:16, Prof Brucee  wrote:

> Ubuntu doesn't return all processes for "ps -e" so I guess there's
> something deeply wrong with /proc.
>
> brucee
>
> On 12/04/2017 12:56 AM, "Mat Kovach"  wrote:
>
> From the man page:
>
> =$ man ps
>
>  PS(1)   PS(1)
>
>  NAME
>   ps, psu - process status
>
>  SYNOPSIS
>   ps [ -pa ]
>
>   psu [ -pa ] [ user ]
>
>  [snip]
>   With the -p flag, ps also prints, after the system time, the
>   baseline and current priorities of each process.
>
>   The -a flag causes ps to print the arguments for the pro-
>   cess.  Newlines in arguments will be translated to spaces
>   for display.
>
> plan9port's ps does not have a '-e' option, if given it is ignore.
>
> Checking the script, ps uses the os version of ps  and the arguments -axww
>
> --
> *From: *"Bruce Ellis" 
> *To: *"Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
> *Sent: *Tuesday, April 11, 2017 2:54:07 AM
> *Subject: *[9fans] ps bug
>
> using plan9ports' "ps -e" does not print all processes. dirread /proc fun
> I guess.
> brucee
>
>
>

Re: [9fans] ps bug

[Prof Brucee]

Ubuntu doesn't return all processes for "ps -e" so I guess there's
something deeply wrong with /proc.

brucee

On 12/04/2017 12:56 AM, "Mat Kovach"  wrote:

>From the man page:

=$ man ps

 PS(1)   PS(1)

 NAME
  ps, psu - process status

 SYNOPSIS
  ps [ -pa ]

  psu [ -pa ] [ user ]

 [snip]
  With the -p flag, ps also prints, after the system time, the
  baseline and current priorities of each process.

  The -a flag causes ps to print the arguments for the pro-
  cess.  Newlines in arguments will be translated to spaces
  for display.

plan9port's ps does not have a '-e' option, if given it is ignore.

Checking the script, ps uses the os version of ps  and the arguments -axww

--
*From: *"Bruce Ellis" 
*To: *"Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
*Sent: *Tuesday, April 11, 2017 2:54:07 AM
*Subject: *[9fans] ps bug

using plan9ports' "ps -e" does not print all processes. dirread /proc fun I
guess.
brucee

Re: [9fans] p9p: 9 ls /dev

[arisawa]

I did more test on david code and found a problem.

-bash$ mk -f mkfile_david
-bash$ o.test_dirread -a /usr/bin |wc
10844336   27266
-bash$ o.test_dirread /usr/bin |wc
10844336   27266
-bash$ ls /usr/bin |wc
110811089719

option -a is for dirreadall.
1108 - 1084 entries are lost.

they are:
o.test_dirread /usr/bin | awk '{print $1}' | sort >/tmp/a
ls /usr/bin | sort >/tmp/b
diff /tmp/a /tmp/b

-bash$ diff /tmp/a /tmp/b
21a22
> SplitForks
240a242,246
> easy_install-2.6
> easy_install-2.7
> efax
> efix
> egrep
461a468,473
> kcc
> kdestroy
> kextutil
> keytool
> kgetcred
> kill.d
675a688,694
> piconv
> piconv5.16
> piconv5.18
> pidpersec.d
> pkgbuild
> pkill
> pl
880a900,904
> spfquery5.18
> splain
> splain5.16
> splain5.18
> split

sorry if I make a mistake, but I suspect readdir_r() has a buffer,
which can make a problem in using dup().

Kenji Arisawa.

> 2017/04/09 13:18、arisawa  のメール：
> 
> thanks david.
> 
> using dup() is very nice idea!
> your code works with
>   CFLAGS=-D__DARWIN_64_BIT_INO_T  # manual is wrong
> and a fix:
> //buf = ((char*)buf) + d_reclen(buf);
>   buf = (struct dirent *)(((char*)buf) + d_reclen(buf));
> and adding
>   #define NAME_MAX 256
> in somewhere.
> 
> now /dev is readable.
> 
> one problem is left.
> 
> my test code:
>   fd = open(dirname,OREAD);
>   if(fd < 0)
>   fatal("%s open error",dirname);
>   while((n = dirread(fd, )) > 0){
>   print("#DBG n=%d\n",n);
>   for(i = 0; i < n; i++)
>   print("%s %s %s \n", db[i].name, db[i].uid, db[i].gid);
>   }
>   close(fd);
> shows for dirname=$HOME
>   ...
>   arch root 501 
>   bin root 501 
>   ...
> but they should be
>   arch arisawa staff 
>   bin arisawa staff
> this problem comes from _p9dir() that is used in dirpackage().
> 
> Kenji Arisawa
> 
> 
>> 2017/04/08 18:07、David Arroyo  のメール：
>> 
>> Ignore my previous post, I was tired and forgot about dup(). How about
>> something like this? (attached)
>> 
>> I only tested this on Ubuntu, I don't have an OS X machine. I still went
>> with readdir_r because the AIX and Solaris man pages for readdir were
>> vague about its behavior when called from multiple threads (glibc, musl,
>> FreeBSD look pretty safe).
>> 
>> Cheers,
>> David
>> 
>> On Sat, Apr 8, 2017, at 03:27 AM, David Arroyo wrote:
>>> This should be doable with some combination of fdopendir(3) and
>>> readdir(3). I'm not sure how to avoid leaking memory through the
>>> returned DIR pointer and any memory allocated with by readdir(3).
>>> This is usually free'd by closedir(3), which we can't use without
>>> closing the underlying file.
>>> 
>>> It should be OK to use free() on the return value of fdopendir, and
>>> stick to the uglier readdir_r(3) interface. I can definitely see why
>>> Russ went with  the simpler  system-specific interfaces on this.
>>> 
>>> David
>>> 
>>> On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote:
 On Sat, 8 Apr 2017 15:21:47 +0900, arisawa  wrote:
 
> but how to?
> 
> unix doesn’t have something like fdreaddir(int fd).
> my guess: russ unwillingly used a low level function such as
> int getdirentries(int fd, char *buf, int nbytes, long *basep).
> 
> readdirall() might be OK in regular usage.
 
 I don't use OSX regularly, although I do maintain the syscall
 layer for Myrddin on it.
 
 Getdirentries64 exists, and rudimentary testing doesn't show
 any difficulties with using it.
 
 -- 
   Ori Bernstein
 
>>> 
>> 
> 

Re: [9fans] ps bug

[Mat Kovach]

>From the man page: 

=$ man ps 

PS(1) PS(1) 

NAME 
ps, psu - process status 

SYNOPSIS 
ps [ -pa ] 

psu [ -pa ] [ user ] 

[snip] 
With the -p flag, ps also prints, after the system time, the 
baseline and current priorities of each process. 

The -a flag causes ps to print the arguments for the pro- 
cess. Newlines in arguments will be translated to spaces 
for display. 

plan9port's ps does not have a '-e' option, if given it is ignore. 

Checking the script, ps uses the os version of ps and the arguments -axww 


From: "Bruce Ellis"  
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> 
Sent: Tuesday, April 11, 2017 2:54:07 AM 
Subject: [9fans] ps bug 

using plan9ports' "ps -e" does not print all processes. dirread /proc fun I 
guess. 
brucee 

Re: [9fans] ps bug

[Sergey Zhilkin]

Hmm checked twice

zhilkin@szhilkin:~/Work/Mem> ps ax | wc -l
350
szhilkin@szhilkin:~/Work/Mem> 9 ps -e | wc -l
350


2017-04-11 10:51 GMT+03:00 Bruce Ellis :

> Doesn't help.
>
> brucee
>
> On 11 April 2017 at 17:21, Sergey Zhilkin  wrote:
>
>> Seems ps (shell script from hell) uses plan9port sort. And coreutils sort
>> do not undarstand +1 parameter.
>>
>> Try to place plan9port path before any other.
>>
>> 2017-04-11 9:54 GMT+03:00 Bruce Ellis :
>>
>>> using plan9ports' "ps -e" does not print all processes. dirread /proc
>>> fun I guess.
>>>
>>> brucee
>>>
>>>
>>
>>
>> --
>> С наилучшими пожеланиями
>> Жилкин Сергей
>> With best regards
>> Zhilkin Sergey
>>
>
>


-- 
С наилучшими пожеланиями
Жилкин Сергей
With best regards
Zhilkin Sergey

Re: [9fans] ps bug

[Bruce Ellis]

Doesn't help.

brucee

On 11 April 2017 at 17:21, Sergey Zhilkin  wrote:

> Seems ps (shell script from hell) uses plan9port sort. And coreutils sort
> do not undarstand +1 parameter.
>
> Try to place plan9port path before any other.
>
> 2017-04-11 9:54 GMT+03:00 Bruce Ellis :
>
>> using plan9ports' "ps -e" does not print all processes. dirread /proc fun
>> I guess.
>>
>> brucee
>>
>>
>
>
> --
> С наилучшими пожеланиями
> Жилкин Сергей
> With best regards
> Zhilkin Sergey
>

Re: [9fans] ps bug

[Sergey Zhilkin]

Also, on Linux (OpenSUSE 42.2) i have same output of p9p ps -e and ps ax in
line count

2017-04-11 10:21 GMT+03:00 Sergey Zhilkin :

> Seems ps (shell script from hell) uses plan9port sort. And coreutils sort
> do not undarstand +1 parameter.
>
> Try to place plan9port path before any other.
>
> 2017-04-11 9:54 GMT+03:00 Bruce Ellis :
>
>> using plan9ports' "ps -e" does not print all processes. dirread /proc fun
>> I guess.
>>
>> brucee
>>
>>
>
>
> --
> С наилучшими пожеланиями
> Жилкин Сергей
> With best regards
> Zhilkin Sergey
>



-- 
С наилучшими пожеланиями
Жилкин Сергей
With best regards
Zhilkin Sergey

Re: [9fans] ps bug

[Sergey Zhilkin]

Seems ps (shell script from hell) uses plan9port sort. And coreutils sort
do not undarstand +1 parameter.

Try to place plan9port path before any other.

2017-04-11 9:54 GMT+03:00 Bruce Ellis :

> using plan9ports' "ps -e" does not print all processes. dirread /proc fun
> I guess.
>
> brucee
>
>


-- 
С наилучшими пожеланиями
Жилкин Сергей
With best regards
Zhilkin Sergey

[9fans] ps bug

[Bruce Ellis]

using plan9ports' "ps -e" does not print all processes. dirread /proc fun I
guess.

brucee