[9fans] 'stuck' windows. - Plan9

This is a discussion on [9fans] 'stuck' windows. - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: [9fans] 'stuck' windows.

  1. [9fans] 'stuck' windows.

    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.


  2. Re: [9fans] 'stuck' windows.

    > 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



  3. Re: [9fans] 'stuck' windows.

    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...



  4. Re: [9fans] 'stuck' windows.

    > 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



  5. Re: [9fans] 'stuck' windows.

    > 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 >[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



  6. Re: [9fans] 'stuck' windows.

    On 6/21/08, erik quanstrom 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.


  7. Re: [9fans] 'stuck' windows.

    On 6/22/08, Russ Cox 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 >[2=1]


    But that's what 9fat: does (well, not literally, since it does 'dossrv
    >/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.


  8. Re: [9fans] 'stuck' windows.

    > But that's what 9fat: does (well, not literally, since it does 'dossrv
    >>/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



  9. Re: [9fans] 'stuck' windows.

    > On 6/22/08, Russ Cox 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 >[2=1]

    >
    > But that's what 9fat: does (well, not literally, since it does 'dossrv
    >>/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



  10. Re: [9fans] 'stuck' windows.

    > 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


  11. Re: [9fans] 'stuck' windows.

    On 6/22/08, Russ Cox 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.


  12. Re: [9fans] 'stuck' windows.

    > 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 $*
    }



  13. Re: [9fans] 'stuck' windows.

    > 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


  14. Re: [9fans] 'stuck' windows.

    On 6/22/08, Russ Cox 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.


+ Reply to Thread