[9fans] what means: cpu: waiting for FS: ?

[9fans] what means: cpu: waiting for FS: ?

[Axel Belinfante]

When trying to 'cpu' from home to work I got the message
	cpu: waiting for FS:
What does it mean? What could be the reason I get it?
At the moment (when I get above message), after giving factotum
the user/password for the auth server at work, I am able to
 - cpu to my auth server at work
 - mount the file system from the fs at work
 - use 'C' to look at the consoles from fs and auth server
   (served via auth server)
but when I try to access my (diskless) cpu server at work
with 'cpu' I get above error message; when I try with con
I seem to be unable to give the right response to the challenge.

I can look tomorrow at the cpu server console, but right now
I'm curious what might be wrong (just before leaving from work
I ran a drawterm session on the cpu server that I closed when I left).

Thanks for any insight,
Axel.

Re: [9fans] what means: cpu: waiting for FS: ?

[Geoff Collyer]

I start factotum on a cpu server from drawterm like this:

		if (! test -f /srv/factotum.$user)
			auth/factotum -s factotum.$user
		mount -b /srv/factotum.$user /mnt

This is sure to leave the existing /srv/factotum (for bootes's
factotum) alone, and also lets me share one factotum across all my cpu
windows.  The one wart is that factotum echoes my secstore password
when I type it (across the encrypted cpu connection).

Re: [9fans] what means: cpu: waiting for FS: ?

[Zoltan Jarai]

I get similar symptoms as Axel when trying to use cpu or drawterm,
from any machine on my home network.  I get two different reactions
from cpu, can't really say, what action triggers which.  (My user name
is zoli.)

term% cpu -d
cpu: writing network: dir: Hangup
term% cpu -d
->Tversion tag 65535 msize 8216 version '9P2000'
<-Rversion tag 65535 msize 8216 version '9P2000'
->Tattach tag 19 fid 303 afid -1 uname zoli aname
<-Rattach tag 19 qid (0000000000000000 0 d)
cpu: waiting for FS: Hangup
->Tclunk tag 19 fid 303
<-Rclunk tag 19
read9pmsg(4) returns 0:
term% notefs exiting:

linux% cpu
drawterm: remote cpu: cpu: srvauth: writing  to #¤/capuse: i/o count too small
[10 garbage chars]
abort 2438
linux%

However, unlike Axel, I do not have any runaway processes on cpu, and
rebooting the cpu server does not help either.  This started
happenning only recently.  Unfortunately, I can't recall what change
in the system triggered this behavior, as I installed some of the
additional software packages, set up secstore, and also did my first
replica/pull /dist/replica/network recently.  I installed 4th edition
at the end of July.

Thanks for any help,

Zoli

Re: [9fans] what means: cpu: waiting for FS: ?

[Axel Belinfante]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="x-unknown", Size: 396 bytes --]

One addition to my previous message, in the hope it might help an expert.
On my sun, I just found in a window the error message from drawterm,
when it was unable to connect to the cpu server
(so, probably when I already had a factotum runnin on cpu server,
 started via another drawterm session):

drawterm: remote cpu: cpu: srvauth: writing  to #¤/capuse: i/o count too small

Axel.

Re: [9fans] what means: cpu: waiting for FS: ?

[Axel Belinfante]

You are I right. I tried removing it without success.
When I run 'cpu -h cpusysname' on the cpu server itself
I get
   cpu: writing network: dir : Hangup
drawterm access does not work either.

I looked at the console of the cpu server.
Seems I indeed had some run-away processes running from my last
drawterm session:

cpu% ps -ef | axel
axel           6061    0:00   0:00     200K Broken   snoopy
axel           7266    0:00   0:00     260K Pread    factotum
axel           7273    0:00   0:00     692K Pread    fs
axel           7274    0:00   0:00     692K Sleep    fs
axel           7405    0:00   0:00     676K Pread    win
axel           7407    0:00   0:00     676K Await    win
axel           7409    0:00   0:00     244K Pread    rc

Killing the fs processes did not change a thing.
However, when I killed the win processes, also factotum went away.
Seems that did the job, now drawterm and cpu work again.
Putting back the trampoline does not seem to matter.
What does seem to matter is that the part of my lib/profile that
gets executed for a drawterm session starts a factotum
(on the cpu server), as follows below.
Could it be that this is not the best way to do things?

Axel.

switch($service){
case terminal
	...
case cpu
	if (test -e /mnt/term/mnt/wsys) {
		# rio already running
		wsys = /mnt/term^`{cat /mnt/term/env/wsys}
		bind -a /mnt/term/mnt/wsys /dev
		echo -n $sysname > /dev/label
	}
#	if not {
#		plumber
#	}
	bind /mnt/term/dev/cons /dev/cons
	bind /mnt/term/dev/consctl /dev/consctl
	bind -a /mnt/term/dev /dev
	prompt=('cpu% ' '	')
	fn cpu%{ $* }
#	upas/fs -b
	news
	if (! test -e /mnt/term/mnt/wsys) {
		# cpu call from drawterm
		@{
			rfork n
			auth/factotum
			if(~ `{wc -l </mnt/factotum/ctl} 0)
				auth/secstore -G factotum | read -m >/mnt/factotum/ctl
			plumber
			upas/fs -b
			font=/lib/font/bit/pelm/latin1.8.font
			rio
			kill plumber |rc
		}
	}
case con
	...
}

> You could always remove the trampoline script
> and see if that fixes things, but I'll be
> very surprised.  Trampoline is just that --
> a trampoline to another network address.
> It dials the address and then ferries bytes
> between stdin/stdout and the newly dialed
> connection.
>

Re: [9fans] what means: cpu: waiting for FS: ?

[Russ Cox]

You could always remove the trampoline script
and see if that fixes things, but I'll be
very surprised.  Trampoline is just that --
a trampoline to another network address.
It dials the address and then ferries bytes
between stdin/stdout and the newly dialed
connection.

Re: [9fans] what means: cpu: waiting for FS: ?

[Lucio De Re]

On Thu, Sep 05, 2002 at 09:40:02AM +0200, Axel Belinfante wrote:
>
> Yes, I'm using the same password.
> Also, what I forgot to mention in my previous post:
> Yesterday (well, by now the day before yesterday) It Worked!
> and of course, I Did Not Change Anything!

In general, I find that is caused by a runtime parameter that gets
reset on boot (I often forget to change startup configuration files in
NetBSD installations and have to remember what's new after a reboot
<sigh>).

> However, I did add the tcp564 trampoline script to /rc/bin/service
> on the (diskless) cpu server, to access the file server via tcp.
> Could that be related?
>
Sounds like it should, but trampoline, as far as I know, is
undocumented so I leave the answer to those who actually know :-)

++L

Re: [9fans] what means: cpu: waiting for FS: ?

[Axel Belinfante]

Yes, I'm using the same password.
Also, what I forgot to mention in my previous post:
Yesterday (well, by now the day before yesterday) It Worked!
and of course, I Did Not Change Anything!
However, I did add the tcp564 trampoline script to /rc/bin/service
on the (diskless) cpu server, to access the file server via tcp.
Could that be related?

I'm still at home, I tried to move the script 'out of the way'
on the file server, but that seems not to stop the listener
(or is it because I already have a connection open?)

I'll have a closer look at the cpu server at work later today.

> It means your terminal at home is unable to authenticate to
> your cpu server at work, and /bin/cpu is not kind enough to
> tell you what went wrong.  It's weirder than that, though.
> The terminal thinks the auth worked, and the cpu server
> thinks it didn't.  That shouldn't happen (the protocol
> is cpu server speaks last).  I've seen this before but
> don't remember what the problem is.  It seems likely
> there's a key mismatch somewhere.  Are you using the
> same password in drawterm and on the terminal?

Re: [9fans] what means: cpu: waiting for FS: ?

[Russ Cox]

It means your terminal at home is unable to authenticate to
your cpu server at work, and /bin/cpu is not kind enough to
tell you what went wrong.  It's weirder than that, though.
The terminal thinks the auth worked, and the cpu server
thinks it didn't.  That shouldn't happen (the protocol
is cpu server speaks last).  I've seen this before but
don't remember what the problem is.  It seems likely
there's a key mismatch somewhere.  Are you using the
same password in drawterm and on the terminal?

Russ