Just to bring the subject back: it seems the DNS server fails when the connectivity it relies on is restored. At least, that is how I interpret what happened this morning.
K some point, my attempts to browse the web failed and looked a lot like a hostname lookup failure, so I applied my now regular sledge-hammer to kill and restart the server (1). That failed in its objective so I actually figured the Internet link had failed. Coincidentally, the mobile data link had run out of credits, so that failed too - nothing seems simple around here. A few steps down the line, I managed to use the second Internet link to provision data for the mobile backup link (2), by which time the Internet link (would you believe that both Internet services run on a long distance wi-fi connection?) had been restored. And that is when I noticed that the Plan 9 DNS server had reached 100, then 200 opened file handles as reported by the kernel console. It seems - I'm hoping someone here knows the DNS server code better than my distant exploration of it - that a fresh instance of the server is more robust against a network failure than one that has run for some time. Presumably some kind of cache problem, as that would be the significant difference. Myself, cache allocation and general messing about is the type of code I try desperately to avoid having to write, let alone debug. (1) Miller informed me that the DNS server responds to a "restart" command, but I discovered that if the "-s" option is used, the restart isn't a complete one. (2) Recently, I rearranged my small network. Out of necessity as I had managed to mis-configure the core gateway and could not restore it in a short time. It used to be that one Internet link did all the work, with a few exceptions to get around ISP-dictated restrictions and misconfigurations. Routing to the second link was used as the anti-censorship measure. When the primary link failed, removing the lower-cost default route sufficed to bring the more expensive secondary into full operation. I wasn't really concerned with failures of the secondary link, they didn't really have much impact. To be honest, even failure of the primary link didn't have much impact. Short failures, though, that would otherwise go unnoticed, I now believe tickled the DNS server into bad behaviour. Not too short, I don't think, but hardly worth switching to the secondary. Since I switched to what used to be the secondary link for all my desktop work and reserved the primary for Netflix and my partner's obsession with Trump's misdemeanours, the DNS server has shown a different pattern of failures, all seemingly related to flakey connectivity. Lucio. PS: those who raised the Osmio flag did so, in my opinion, disingenuously. Wes has long been known to punt a socially-related issue. Probably something that needs no further attention in this thread. On 10/27/20, Thaddeus Woskowiak <tswoskow...@gmail.com> wrote: > On Sat, Oct 24, 2020 at 10:11 PM Wes Kussmaul <w...@reliableid.com> wrote: >> >> Lucio's concern was about commercial enterprises bending Internet norms >> to serve their bottom line at the expense of interoperation. >> >> Imagine if the physical city where you live allowed building codes to be >> proprietary, and instead of public professional licensing of architects, >> contractors, structural engineers and building inspectors you had >> certification programs of those commercial enterprises. >> >> Instead, habitability of physical buildings is determined by building >> codes and professional licensing that are the product of participatory >> and duly constituted public authority. >> >> That's the role that Osmio sets out to play in non-physical digital >> indoor spaces. >> >> >> On 10/24/20 6:48 PM, Charles Forsyth wrote: >> > It's a virtual city in Switzerland, which is famously neutral (hence >> > Geneva as location for various international organisations, and indeed >> > as a setting for several TV series) >> > >> > On Sat, Oct 24, 2020 at 11:23 PM <cigar562hfsp952f...@icebubble.org >> > <mailto:cigar562hfsp952f...@icebubble.org>> wrote: >> > >> > Wes Kussmaul <w...@reliableid.com> writes: >> > >> > > On 10/7/20 12:08 AM, Lucio De Re wrote: >> > >> my situation is getting >> > >> more difficult as norms on the Internet are being bent by >> > service >> > >> provider that care for their profitability much more than for >> > >> interoperation >> > > >> > > I suggest taking a look at https://www.osmio.ch/ >> > >> > I don't get it. That Web site appears to be the municipal >> > homepage for >> > a city in Switzerland that uses digital certificates as official >> > government-recognized ID. What does that have to do with anything? >> > >> > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions >> > <https://9fans.topicbox.com/groups/9fans> + participants >> > <https://9fans.topicbox.com/groups/9fans/members> + delivery options >> > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink >> > <https://9fans.topicbox.com/groups/9fans/T4e8db4c94a81d90f-M99ae9635befa9785b4527671> >> -- >> >> *Wes Kussmaul* >> >> *Reliable Identities, Inc.* >> an Authenticity Enterprise >> 738 Main Street >> Waltham, MA 02451 USA >> t: +1 781 790 1674 >> m: +1 781 330 1881 >> e: w...@reliableid.com <mailto:w...@reliableid.com> >> >> Learn About Authenticity <http://authenticityworks.video/> >> >> This message is confidential. It may also be privileged or otherwise >> protected by work product immunity or other legal rules. If you have >> received it by mistake, please let us know by e-mail reply and delete it >> from your system; you may not copy this message or disclose its contents >> to anyone. The integrity and security of this message cannot be assured >> unless it is digitally signed by the PEN of an identity certificate with >> an IDQA score that is sufficient for your purposes. >> > > I believe the issue here is that some people have interpreted your > osmio.ch suggestion as a solution to Lucio's DNS issues. -- Lucio De Re 2 Piet Retief St Kestell (Eastern Free State) 9860 South Africa Ph.: +27 71 471 3694 Cell: +27 83 251 5824 ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4e8db4c94a81d90f-M6b99f77537610c267cebc5dd Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
