[OpenAFS] Graphical file managers get stuck
Mon, 10 Dec 2012 16:49:59 -0500
For your home cell I assume you are using DNS AFSDB records. 1.6 looks for D=
NS SRV records first, then fails over to AFSDB if they are not found. Publi=
sh DNS SRV records for your cell.
On Dec 10, 2012, at 4:45 PM, firstname.lastname@example.org wrote:
> Thanks Jeffrey, that explains things nicely. Eventhough the dns-lookups
> work, I suspect it is far from optimal. If the lookup takes a fair amount
> of time on top of nautilus fetching the afs content itself, it can very
> well be enough to cause the timeout. Once you can cache the location and
> content enough, there's enough time for nautilus to succeed.
> BTW, I tried openafs 1.6. together with fakestat-all and dynroot-sparse a
> bit earlier but nautilus behaved the same and unfortunately atleast the
> login phase is still slower than in 1.4. (GDM & LDAP & AFS homedirs).
> I did receive a new error message which deals with dbus as well.
> (nautilus:12750): Unique-DBus-WARNING **: Error while sending message: Did=
> not receive a reply. Possible causes include: the remote application did
> not send a reply, the message bus security policy blocked the reply, the
> reply timeout expired, or the network connection was broken.
> This seems to be a symptom rather than the cause, so I'm still suspecting
> DNS issues.
> Now, back to the investication... Thanks everybody!
> br, jukka
>> -fakestat provides no benefits if the application is going to read the
>> contents of the volume root directory referenced by a mount point.
>> -fakestat works by generating fake stat info for the mount point target
>> instead of reading the actual data belonging to the target which might
>> require a volume location database lookup in addition to the file server
>> fetch status RPC. There might even need to be DNS queries to find the
>> locations of the VLDB servers in the foreign cell.
>> Jeffrey Altman
>> On Dec 10, 2012, at 1:22 PM, email@example.com wrote:
>>> Hmmm... Strange things happened. After several hang-ups, being more
>>> patient they turned into time-outs, until... even nautilus could get
>>> through! First I thought that initiating nautilus from the command line
>>> as part of strace command - did something, but then I could browse (in
>>> veeeery slow motion) directly within nautilus.
>>> Now it seems more likely that eventhough fakestat does its thing within
>>> the local cell (or is otherwise just faster), the same thing isn't
>>> happening with the foreign cells (or it is just too slow). Once the dir
>>> content is displayed, nautilus continues to dig deeper into subdirs on
>>> background, adding the number of items one-by-one. So it seems it hasn't=
>>> scanned all-of-all before displaying the content!?
>>> Should fakestat-all instead of fakestat solve this situation? How
>>> should I tweak the configuration to have it started on boot, and how can=
>>> verify that it is on?
>>> br, jukka
>>>> On Sun, Dec 9, 2012 at 3:37 PM, <firstname.lastname@example.org> wrote:
>>>>> By "own-path" I mean local cell as opposed to foreign one.
>>>> Oh, this may not be the same issue then. On my computer I see the GUI
>>>> freezes happening for my local cell.
>>>> You can try running nautilus through strace or gdb to see what
>>>> specifically is hanging:
>>>> $ strace /usr/bin/nautilus
>>>> You probably want to ensure no other Nautilus processes are running
>>>> before you do that (ps -A | grep nautilus).
>>>> It's possible Wireshark or tcpdump might tell you more as well. I
>>>> would start by sniffing on the ports for DNS, Kerberos, and AFS:
>>>> $ tcpdump "port 53 and port 88 and portrange 7000-7005"
>>>> (or use that filter in Wireshark)
>>>> - Ken
>>>> OpenAFS-info mailing list
>>> OpenAFS-info mailing list
>> OpenAFS-info mailing list