[OpenAFS] Graphical file managers get stuck

[jukka.tuominen@finndesign.fi]

What do you mean by publishing DNS SRV records? The server has a FQDN but
do you mean something else?

Possibly a related issue. Our ISP rearranged IP addresses, and eventhough
it wasn't an issue for the server end, the client is a read-only image.
This time the IP number had to be changed manually, but for future, I
wonder if there is a way to figure it out dynamically based on the domain
name only?

br, jukka


> For your home cell I assume you are using DNS AFSDB records.  1.6 looks
> for DNS SRV records first, then fails over to AFSDB if they are not found.
>  Publish DNS SRV records for your cell.
>
> Jeffrey Altman
>
>
> On Dec 10, 2012, at 4:45 PM, jukka.tuominen@finndesign.fi 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, jukka.tuominen@finndesign.fi 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
>>>> the
>>>> 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
>>>> exactly
>>>> should I tweak the configuration to have it started on boot, and how
>>>> can
>>>> I
>>>> verify that it is on?
>>>>
>>>> br, jukka
>>>>
>>>>
>>>>
>>>>> On Sun, Dec 9, 2012 at 3:37 PM,  <jukka.tuominen@finndesign.fi>
>>>>> 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@openafs.org
>>>>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenAFS-info mailing list
>>>> OpenAFS-info@openafs.org
>>>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>>
>>> _______________________________________________
>>> OpenAFS-info mailing list
>>> OpenAFS-info@openafs.org
>>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>>
>>
>>
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>