[Coco] Tutorial on Telnet/inetd on Coco3 DW4 (is there one?)

[Gene Heskett]

On Thursday 11 October 2012 15:19:48 Gene Heskett did opine:

> On Thursday 11 October 2012 12:47:34 Bill Pierce did opine:
> > Gene, I've been fololowing the conversaton up the end, then you got
> > me... what the heck is an "lsof" ?
> > 
> > Bill P
> 
> I can tell you are running winderz Bill, shame on you. ;)
> 
> In the *nix's the ls command is generall equ to the dir command,
> returning a list of files.  But the idea has been expanded to 'lsXX' a
> lot of stuff.
> 
> lsusb for instance can give one an output list of all the devices
> plugged into a machines usb bus.
> 
> lsof returns a list of open files, which on the *nix's can be piped to
> wc (word count) or grep to derive other information, like this:
> 
> root at coyote:~# lsof | wc -l
> lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system
> /home/gene/.gvfs Output information may be incomplete.
> 11620
> 
> So there are at the moment 11620 open files on this system.  The wc -l
> tells it not to count words, but to count lines.  Or if I wanted to see
> what the 2nd generation inetd is doing on this machine:
> 
> root at coyote:~# lsof|grep inetd
> lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system
> /home/gene/.gvfs Output information may be incomplete.
> xinetd     2968       root  cwd       DIR        8,2       4096         
> 2 / xinetd     2968       root  rtd       DIR        8,2       4096    
>      2 / xinetd     2968       root  txt       REG        8,2    
> 153144   23989230 /usr/sbin/xinetd xinetd     2968       root  mem     
>  REG        8,2     149392   38408414 /lib/tls/i686/cmov/libm-2.11.1.so
> xinetd     2968       root  mem       REG        8,2    1430084  
> 38408412 /lib/tls/i686/cmov/libc-2.11.1.so xinetd     2968       root 
> mem       REG        8,2      34408   38408404
> /lib/tls/i686/cmov/libnss_nis-2.11.1.so xinetd     2968       root  mem
>       REG        8,2     113964   38408635 /lib/ld-2.11.1.so xinetd    
> 2968       root  mem       REG        8,2      42572   38408408
> /lib/tls/i686/cmov/libnss_files-2.11.1.so xinetd     2968       root 
> mem       REG        8,2      38360   38404218
> /lib/tls/i686/cmov/libcrypt-2.11.1.so xinetd     2968       root  mem  
>     REG        8,2      31020   38404295 /lib/libwrap.so.0.7.6 xinetd  
>   2968       root  mem       REG        8,2      30496   38408424
> /lib/tls/i686/cmov/libnss_compat-2.11.1.so xinetd     2968       root 
> mem       REG        8,2      79676   38408421
> /lib/tls/i686/cmov/libnsl-2.11.1.so xinetd     2968       root    0r   
>   CHR        1,3        0t0        988 /dev/null xinetd     2968      
> root    1r      CHR        1,3        0t0        988 /dev/null xinetd  
>   2968       root    2r      CHR        1,3        0t0        988
> /dev/null xinetd     2968       root    3r     FIFO        0,8       
> 0t0      16637 pipe xinetd     2968       root    4w     FIFO       
> 0,8        0t0      16637 pipe xinetd     2968       root    5u    
> IPv4      16818        0t0        TCP *:sane-port (LISTEN)
> 
> The emphasis on the *nix's is to do one small thing well, and if thats
> too much info, then pipe it to grep to pass only that which is of
> interest.
> 
> We need an lsof for nitros9.  It might even be possible, I'll check the
> syscall menu for something that I can iterate thru the system with.  We
> do have a grep BTW, works well.
> 
> Cheers, Gene

This might not be possible in nitros9.  I seems that the pathlist the 
*nix's maintain seems to be thrown away after converting, by way of the 
open command converting it into a 1 byte path number by os9.  The pathlist 
string itself is not saved.  So we would need some of that magic in step 35 
of that famous wall of blackboards full of procedure to decode it.

At this point, even a log kept by the I$Open and I$close functions, which 
do have access to the pathlist strings at open time, would be handier than 
bottled beer or sliced bread.

So, only Aaron can answer this question:  Does inetd ever close that path 
to /sys/inetd.conf?  Seems like it should once it has read it, but, even 
with it redirected to another screen, it does have an open path to /DD 
according to proc.

If it does hold it open, why?  And if "kill"ed, does it clean up before 
exiting?

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
If elected, Zippy pledges to each and every American a 55-year-old houseboy 
...