[OpenAFS] Graphical file managers get stuck

[Jeffrey Altman]

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.

Jeffrey Altman


On Dec 10, 2012, at 4:45 PM, jukka.tuominen@finndesign.fi wrote:

>=20
> 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.
>=20
> 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).
>=20
> I did receive a new error message which deals with dbus as well.
>=20
> (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.
>=20
> This seems to be a symptom rather than the cause, so I'm still suspecting
> DNS issues.
>=20
> Now, back to the investication... Thanks everybody!
>=20
>=20
> br, jukka
>=20
>=20
>=20
>=20
>> -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.
>>=20
>> Jeffrey Altman
>>=20
>>=20
>> On Dec 10, 2012, at 1:22 PM, jukka.tuominen@finndesign.fi wrote:
>>=20
>>>=20
>>> 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.
>>>=20
>>> 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
>>> the
>>> background, adding the number of items one-by-one. So it seems it hasn't=

>>> scanned all-of-all before displaying the content!?
>>>=20
>>> Should fakestat-all instead of fakestat solve this situation? How
>>> exactly
>>> should I tweak the configuration to have it started on boot, and how can=

>>> I
>>> verify that it is on?
>>>=20
>>> br, jukka
>>>=20
>>>=20
>>>=20
>>>> On Sun, Dec 9, 2012 at 3:37 PM,  <jukka.tuominen@finndesign.fi> wrote:
>>>>>=20
>>>>> By "own-path" I mean local cell as opposed to foreign one.
>>>>=20
>>>> Oh, this may not be the same issue then. On my computer I see the GUI
>>>> freezes happening for my local cell.
>>>>=20
>>>> You can try running nautilus through strace or gdb to see what
>>>> specifically is hanging:
>>>>=20
>>>> $ strace /usr/bin/nautilus
>>>>=20
>>>> You probably want to ensure no other Nautilus processes are running
>>>> before you do that (ps -A | grep nautilus).
>>>>=20
>>>> 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:
>>>>=20
>>>> $ tcpdump "port 53 and port 88 and portrange 7000-7005"
>>>>=20
>>>> (or use that filter in Wireshark)
>>>>=20
>>>> - Ken
>>>> _______________________________________________
>>>> OpenAFS-info mailing list
>>>> OpenAFS-info@openafs.org
>>>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>>=20
>>>=20
>>> _______________________________________________
>>> OpenAFS-info mailing list
>>> OpenAFS-info@openafs.org
>>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>=20
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>=20
>=20
>=20