[9fans] 'stuck' windows.

[9fans] 'stuck' windows.

[Sander van Dijk]

Hi,

When I open a window in rio, run 9fat:, and then exit, the window gets
'stuck'. That is, it just sits there, I can't type anything in it
anymore.
Apparently, it is waiting for dossrv to exit (which gets started by
9fat:): when I open a second window, and run 'kill dossrv | rc', the
first window disappears.
Also, when this first window is still waiting, and I run 9fat: from a
second window, I can exit the second window without problems (because
9fat: only starts dossrv if it isn't there already, and in this case
the first window has already started it).

This (being unable to exit the window without killing dossrv) seems a
bit strange to me. I can of course destroy the window using the
'Delete' option in rio's menu, but I think that's not the 'right' way
to do it.
Am I doing something wrong (is there a way I can actually exit said
window without killing dossrv)?
Has it always been this way (I believe I vaguely remember that
somewhere in the past I could exit from the window that started dossrv
without problems)?

Greetings, Sander.

Re: [9fans] 'stuck' windows.

[erik quanstrom]

> This (being unable to exit the window without killing dossrv) seems a
> bit strange to me. I can of course destroy the window using the
> 'Delete' option in rio's menu, but I think that's not the 'right' way
> to do it.
> Am I doing something wrong (is there a way I can actually exit said
> window without killing dossrv)?
> Has it always been this way (I believe I vaguely remember that
> somewhere in the past I could exit from the window that started dossrv
> without problems)?

unmount /n/9fat if you think this is a problem.

- erik

Re: [9fans] 'stuck' windows.

[Pietro Gagliardi]

On Jun 21, 2008, at 2:21 PM, Sander van Dijk wrote:
> This (being unable to exit the window without killing dossrv) seems a
> bit strange to me. I can of course destroy the window using the
> 'Delete' option in rio's menu, but I think that's not the 'right' way
> to do it.
> Am I doing something wrong (is there a way I can actually exit said
> window without killing dossrv)?
> Has it always been this way (I believe I vaguely remember that
> somewhere in the past I could exit from the window that started dossrv
> without problems)?

It's happened to me quite often. I think rc should kill all
subprocesses on exit, but I don't think dossrv handles the hangup
note: adding

	postnote(NPGROUP, getpid(), "hangup");

to plan9.c:Exit() and trying

	a: & exit # no floppy disk drive (QEMU) keeps a: hanging

does nothing. What I do is I put 9fat:, 9fs wiki, 9fs sources in my
profile to run automatically.

How I wish Plan 9 had kill -9! The kernel uses the note

	sys: killed

internally, but notify(2) doesn't say so. I wonder...

Re: [9fans] 'stuck' windows.

[Russ Cox]

> It's happened to me quite often. I think rc should kill all
> subprocesses on exit

No.  It shouldn't, and it doesn't.

> How I wish Plan 9 had kill -9! The kernel uses the note
>
> 	sys: killed
>
> internally, but notify(2) doesn't say so. I wonder...

Plan 9 is not Unix.

	echo kill >/proc/pid/ctl
	slay dossrv | rc

Russ

Re: [9fans] 'stuck' windows.

[Russ Cox]

> When I open a window in rio, run 9fat:, and then exit, the window gets
> 'stuck'. That is, it just sits there, I can't type anything in it
> anymore.
> Apparently, it is waiting for dossrv to exit (which gets started by
> 9fat:): when I open a second window, and run 'kill dossrv | rc', the
> first window disappears.

It is not waiting for dossrv to exit,
so much as it is waiting for all the open
file descriptors referring to that window's
/dev/cons to be closed.  Dossrv just happens
to be the one holding them.

The window is reference-counted, and
there are still references.  Try this in a window:

	{sleep 2; echo hello world; sleep 2}& exit

Probably the various dossrv'ing scripts should run

	dossrv </dev/null >/dev/null >[2=1]

but then you do lose any errors from dossrv.
On the other hand, if dossrv does error out
you'd still get an error from mount about #s/dos
not existing, so you would get *some* output.

> Am I doing something wrong (is there a way I can actually exit said
> window without killing dossrv)?

No, and no.  Well, except for starting dossrv
differently.

> Has it always been this way

I think it has.

Russ

Re: [9fans] 'stuck' windows.

[Sander van Dijk]

On 6/21/08, erik quanstrom <quanstro@quanstro.net> wrote:
> unmount /n/9fat if you think this is a problem.

Sorry, I should have mentioned this in my initial mail, but it also
happens when I unmount /n/9fat (and /n/9) before trying to exit.

Re: [9fans] 'stuck' windows.

[Sander van Dijk]

On 6/22/08, Russ Cox <rsc@swtch.com> wrote:
> It is not waiting for dossrv to exit,
> so much as it is waiting for all the open
> file descriptors referring to that window's
> /dev/cons to be closed.  Dossrv just happens
> to be the one holding them.
>
> Probably the various dossrv'ing scripts should run
>
> 	dossrv </dev/null >/dev/null >[2=1]

But that's what 9fat: does (well, not literally, since it does 'dossrv
>/dev/null </dev/null >[2]/dev/null', but it means the same). So then
dossrv shouldn't be holding the window's /dev/cons open, right?

>> Has it always been this way
>
> I think it has.

I just found an old cdrom (20070810), and it happens there as well, so
I guess my memory was playing tricks on me here.

Greetings, Sander.

Re: [9fans] 'stuck' windows.

[erik quanstrom]

> On 6/22/08, Russ Cox <rsc@swtch.com> wrote:
>> It is not waiting for dossrv to exit,
>> so much as it is waiting for all the open
>> file descriptors referring to that window's
>> /dev/cons to be closed.  Dossrv just happens
>> to be the one holding them.
>>
>> Probably the various dossrv'ing scripts should run
>>
>> 	dossrv </dev/null >/dev/null >[2=1]
>
> But that's what 9fat: does (well, not literally, since it does 'dossrv
>>/dev/null </dev/null >[2]/dev/null', but it means the same). So then
> dossrv shouldn't be holding the window's /dev/cons open, right?

russ is should be correct.

i think that dossrv's quirks are surprising.  the
redirection in 9fat: is superfluous since 9fat opens
/dev/null on fds 0 and 1 and it makes this surprise
move for fd 2:

	if(!chatty){
		close(2);
		open("#c/cons", OWRITE);
	}

that's downright antisocial.  maybe there's a good
reason.  but i can't think of one now.

- erik

Re: [9fans] 'stuck' windows.

[Russ Cox]

> But that's what 9fat: does (well, not literally, since it does 'dossrv
>>/dev/null </dev/null >[2]/dev/null', but it means the same). So then
> dossrv shouldn't be holding the window's /dev/cons open, right?

What I wrote yesterday was correct but incomplete.
In addition to the file descriptors, dossrv is holding
up a reference to the window's name space, in which
the window files are still accessible.  If you do

	slay dossrv |rc  # clean slate
	unmount /mnt/wsys /dev
	unmount /mnt/wsys
	9fat:
	exit

then the window does in fact disappear.

Russ

Re: [9fans] 'stuck' windows.

[erik quanstrom]

> i think that dossrv's quirks are surprising.  the
> redirection in 9fat: is superfluous since 9fat opens
> /dev/null on fds 0 and 1 and it makes this surprise
> move for fd 2:
>
> 	if(!chatty){
> 		close(2);
> 		open("#c/cons", OWRITE);
> 	}
>
> that's downright antisocial.  maybe there's a good
> reason.  but i can't think of one now.

this is wrong.

- erik

Re: [9fans] 'stuck' windows.

[Sander van Dijk]

On 6/22/08, Russ Cox <rsc@swtch.com> wrote:
> What I wrote yesterday was correct but incomplete.
> In addition to the file descriptors, dossrv is holding
> up a reference to the window's name space, in which
> the window files are still accessible.  If you do
>
> 	slay dossrv |rc  # clean slate
> 	unmount /mnt/wsys /dev
> 	unmount /mnt/wsys
> 	9fat:
> 	exit
>
> then the window does in fact disappear.

Thanks for clearing that up.

I was wondering if it would be possible to start dossrv in a new
namespace, built from scratch, so I've been playing a bit with rfork
(the rc builtin).
However, when I do a 'rfork N', my namespace is empty after that (of
course), but I'm not sure how to get it populated again? Since /bin is
gone, I'm can't do much beside using rc's builtins, of which 'exit'
seems to be the most useful at that point...

Greetings, Sander.

Re: [9fans] 'stuck' windows.

[Russ Cox]

> I was wondering if it would be possible to start dossrv in a new
> namespace, built from scratch, so I've been playing a bit with rfork
> (the rc builtin).
> However, when I do a 'rfork N', my namespace is empty after that (of
> course), but I'm not sure how to get it populated again? Since /bin is
> gone, I'm can't do much beside using rc's builtins, of which 'exit'
> seems to be the most useful at that point...

Rob wrote the script below, called "namespace", years ago.
It is essentially a script version of newns.
You could do

	9fs boot
	namespace /n/boot dossrv

if you really wanted to, but that seems like overkill to me.

Just FYI, you are mucking around in one of the
least satisfactory parts of the system: dossrv, 9660srv, etc.
The fact that they interpret the mount spec as a file name
in their own name space means that if you already have
dossrv running in one window and do

	import othermachine /dev/sdC0
	mount /srv/dos /n/other /dev/sdC0/dos

dossrv doesn't see othermachine's disks.  So in general
you wouldn't want dossrv itself to clear its name space,
and it is debatable whether 9fat, c:, etc. should.

Dossrv is one of those programs that it's best just to use
and not think too much about.

Russ


#!/bin/rc

rfork en

# adapted from /lib/namespace

if(~ $#* 0 || ! test -x $1/$cputype/bin/bind) {
	echo 'usage: namespace /n/foo' >[1=2]
	echo '	/n/foo/$cputype/bin/bind must exist' >[1=2]
	exit usage
}

root = $1
echo setting up $root

fn bind{
	/$cputype/bin/bind $*
}

# root
bind  $root /
bind -b '#/' /

# kernel devices
bind '#c' /dev
bind '#d' /fd
bind -c '#e' /env
bind '#p' /proc
bind -c '#s' /srv
bind -a '#S' /dev

# standard bin
bind /$cputype/bin /bin
bind -a /rc/bin /bin

ramfs
cd
prompt=(`{basename $root}^'=; ' '	')
fn cd

if(~ $#* 1)
	exec rc -i
if not{
	shift
	exec $*
}

Re: [9fans] 'stuck' windows.

[Dave Eckhardt]

> Just FYI, you are mucking around in one of the
> least satisfactory parts of the system: dossrv, 9660srv, etc.
> The fact that they interpret the mount spec as a file name
> in their own name space means that if you already have
> dossrv running in one window and do
>
> 	import othermachine /dev/sdC0
> 	mount /srv/dos /n/other /dev/sdC0/dos
>
> dossrv doesn't see othermachine's disks.

Could a wrapper around mount open /dev/sdC0/dos, post the fd
to /srv, and then pass the /srv pathname as the spec?

Dave Eckhardt

Re: [9fans] 'stuck' windows.

[Sander van Dijk]

On 6/22/08, Russ Cox <rsc@swtch.com> wrote:
> Rob wrote the script below, called "namespace", years ago.
> It is essentially a script version of newns.
> You could do
>
> 	9fs boot
> 	namespace /n/boot dossrv
>
> if you really wanted to, but that seems like overkill to me.

It sure would be. My main reason for exploring this was to learn how
to do it, not necessarily because it would be a good idea to actually
do it.

> Just FYI, you are mucking around in one of the
> least satisfactory parts of the system: dossrv, 9660srv, etc.
> The fact that they interpret the mount spec as a file name
> in their own name space means that if you already have
> dossrv running in one window and do
>
> 	import othermachine /dev/sdC0
> 	mount /srv/dos /n/other /dev/sdC0/dos
>
> dossrv doesn't see othermachine's disks.  So in general
> you wouldn't want dossrv itself to clear its name space,
> and it is debatable whether 9fat, c:, etc. should.

Thanks for the explanation, it answers a question I hadn't asked yet:
I was wondering why the usbfat: script starts a new dossrv (posting it
under /srv/usbfat.$user), rather than reusing a possibly already
exisiting dossrv. (One of) the reason(s) is that the files in /n/disk
it needs most likely aren't available to any existing instance of
dossrv.

Greetings, Sander.