On Fri, 5 Dec 2014, Nikolaus Rath wrote:
Shannon Dealy <de...@deatech.com> writes:
On Thu, 4 Dec 2014, Nikolaus Rath wrote:
Shannon Dealy <de...@deatech.com> writes:
[snip]
Unfortunately Linux does not provide an easy way to distinguish between
an unavailable DNS server, and an un-resolvable host name. To
distinguish these cases, S3QL/Dugong attempts to resolve a number of
"test" hostnames. If these resolve, but the S3 hostname does not,
S3QL/Dugong concludes that this hostname is not resolvable and
terminates. Otherwise it assumes that the DNS server is currently not
reachable and retries.
Attempting to resolve hostnames on your system frequently fails
(sometimes 3 times in a row), and sometimes it's apparently sufficiently
flaky that
1. server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com cannot
be resolved
2. Any of google.com, iana.org, or root-servers.net can be resolved
3. server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com cannot
be resolved
in this order, and without any waiting times.
It occurs to me that the above can be problematic as a test under some
senarios. When segmentation of the internet occurs, routing and DNS
(from a given location) is often lost to some but not all major players.
On a couple of occasions I have been unable to resolve google.com but
could resolve debian.org, amazon.com and many other sites. I understand
your approach and reasoning, and at the moment can't think of a better
solution to what you are trying to do here, however, even if my network
link and DNS server are running flawlessly, events can occur on the
internet where where my connection will fail the above test.
[snip]
The relevant code in S3QL 2.2 was last touched in version 2.2, so I
don't think that's it. However, relevant code in Dugong was last
modified in version 3.2. Prior to 3.2, *any* DNS problem was considered
temporary. In 3.2 and later, DNS problems are only considered temporary
of *no* hostname can be resolved.
The problem with the prior behavior was that it would permanently retry
even in situations like this:
mkfs.s3ql s3://mybucket.aws.s3.cmo
Having this command block for any significant amount of time in the hope
that the wrong hostname becomes resolvable was rather surprising, and
people complained that their scripts would just hang instead of properly
reporting an error.
It seems for you the situation is the other way around...
Which proves once again that you just can't win in life :-)
Given the senario you were trying to fix with the change, perhaps a better
approach would be to fail if initial resolution fails, but if the
initial resolution succeeds, then the end point can reasonably be assumed
to exist and future failures should keep retrying, at least for a
substantial (possibly configurable) period of time. This provides the
immediate feedback for manual or scripting related interactions, but once
the file system is mounted focuses on maintaining/recovering the
connection.
Personally, I would love it if I could simply keep the file system mounted
at all times, even when there is no network link, so that when there is a
connection I can simply start using it, and when the connection goes away
(even for a day or two), everything blocks and simply picks up where it
left off when the connection returns. I often leave my sshfs mount
connected this way as it recovers when the link returns.
Of course my use-case may be different from others, I use it for
maintaining laptop backups and access to data that won't fit on my
laptop drive. This means that network connections come and go multiple
times each day as I move between different locations, and stay down
whenever I don't use the laptop for a few days.
FWIW.
Shannon C. Dealy | DeaTech Research Inc.
de...@deatech.com | - Custom Software Development -
USA Phone: +1 800-467-5820 | - Natural Building Instruction -
numbers : +1 541-929-4089 | www.deatech.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
