[6555] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: new dialup testing

daemon@ATHENA.MIT.EDU (Evan Broder)
Thu Dec 10 14:05:57 2009

MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.00.0912101355450.32528@green-arrow.mit.edu>
Date: Thu, 10 Dec 2009 14:05:07 -0500
Message-ID: <2706d8dd0912101105w15348817pe3bedfe52b78dee@mail.gmail.com>
From: Evan Broder <broder@MIT.EDU>
To: "Mark W. Manley" <mmanley@mit.edu>
Cc: Anders Kaseorg <andersk@mit.edu>, Nelson Elhage <nelhage@mit.edu>,
   release-team@mit.edu, ops@mit.edu
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Flag: NO
X-Spam-Score: 0.00
Content-Transfer-Encoding: 8bit

Huh - I'm not sure why anything would have ever ended up in /mit - if
the automounter is running correctly, all of the /mit symlinks are
part of the PyHesiodFS FUSE filesystem, and should vanish when it gets
unmounted.

We can definitely add logic in the startup script to clean it out,
though. I don't see /etc/init.d/update-ws on any of the Linux or
Solaris Athena 9 machines I can get into, though - where did that come
from?

- Evan

On Thu, Dec 10, 2009 at 1:58 PM, Mark W. Manley <mmanley@mit.edu> wrote:
> It appears that it failed to start because old attach points were still in
> /mit when the system rebooted:
>
> root@ringworld:/etc/init.d# /usr/bin/pyhesiodfs /mnt
> fuse: mountpoint is not empty
> fuse: if you are sure this is safe, use the 'nonempty' mount option
> Traceback (most recent call last):
>  File "/usr/bin/pyhesiodfs", line 226, in <module>
>    main()
>  File "/usr/bin/pyhesiodfs", line 223, in main
>    server.main()
>  File "/usr/lib/python2.6/dist-packages/fuse.py", line 713, in main
>    main(**d)
> fuse.FuseError: filesystem initialization failed
>
> It appears that the same logic that was in /etc/init.d/update-ws to clean
> out /mit isn't present on this system, so it failed to start.
>
> Was this a deliberate change from Athena 9?
>
> -MM
>
> On Thu, 10 Dec 2009, Evan Broder wrote:
>
>> Right. Also, even if attach on linerva fails because he doesn't have
>> tokens, you would still be able to chdir into your homedir because of
>> the automounter, so long as your homedir was system:anyuser l. But it
>> doesn't look like the automounter is running on ringworld - why not?
>>
>> - Evan
>>
>> On Thu, Dec 10, 2009 at 1:33 PM, Anders Kaseorg <andersk@mit.edu> wrote:
>>>
>>> On Thu, 10 Dec 2009, Mark W. Manley wrote:
>>>>
>>>> That's the same behavior of Linerva.
>>>
>>> Linerva gives you a clear warning message in this case.
>>>
>>> WARNING: You have no valid Kerberos tickets.
>>> See http://debathena.mit.edu/ssh
>>>
>>> Nelson was complaining that this warning did not appear on ringworld,
>>> although he told me that it did appear when he tried again, so *shrug*.
>>>
>>> Anders
>>>
>>
>


home help back first fref pref prev next nref lref last post