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.tuomi...@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.tuomi...@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.tuomi...@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 > _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
