27 Apr
2022
27 Apr
'22
2:05 a.m.
I'll have a look some more, then; I haven't crashed any of my Unix boxes
in a while.
I finally found the pernicious bug I that introduced into TTYSRV when I
was updating it to make my life in the Access Control Job easier. In
short, you will sometimes get what deserve if you dereference an index
register that you naively thought somebody else set up for you. If you
happen to do this in Exec mode, then you will be ever-so-more richly
rewarded.
What a rabbit hole... Still, now PANDA can remark on who is looking
over who's shoulder.
Nice to finally come up for air, anyway.
On 4/26/22 6:47 PM, Johnny Billquist wrote:
Hi.
On 2022-04-26 23:03, Thomas DeBellis wrote:
Johnny,
Funny you should say that.
As soon as you responded below, I had a look at bridge.c. Basically
it looks like I'd just need to do a cfork(). That child process would
wake up ever so often and do a gethostbyname() on each name field in
the BRIDGE structure and compare that IP address with what was in the
corresponding addr field. Any difference would mean it would send
the parent a SIGHUP to reparse the bridge.conf file, which would
rebuild the BRIDGE structure with the correct IP addresses.
If we wanted to keep the accumulated totals (rcount, zcount, Etc.)
correct for SIGUSR1, then maybe those could be saved before the
SIGHUP and added back after this was complete.
That doesn't sound too awful, unless I'm missing something (haven't
really gotten into that code for a year or two).
No. You are right. That could definitely be done. I've just been to
lazy to ever start polishing things...
Johnny
--T
------------------------------------------------------------------------
On 4/26/22 3:45 PM, Johnny Billquist wrote:
Well. The thing is, this was/is a listening socket. So there is no
reconnecting. It's just about binding.
> ------------------------------------------------------------------------
>
>
> On 2022-04-26 19:40, Paul Koning wrote:
>
> PyDECnet rechecks the name resolution every hour. It doesn't close
> existing connections, but if a node moves and its DNS entry is
> updated to reflect that, PyDECnet will find it again and reconnect
> within an hour.
>
>> ------------------------------------------------------------------------
>>
>>
>> On Apr 26, 2022, at 1:22 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
>>
>> The problem is that dynamic dns don't necessarily solve any
>> problems. The address is bound at start, and if the resolution in
>> DNS changes at some later point, that won't get reflected unless
>> pydecnet would redo the name lookup, close and reopen the
>> listening socket bound to the new address.
>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se