|
Upon booting up the Pi... the dashboard shows that a connection exists when it does not.
|
Sorry, I'm coming up with a blank. What sort of a connection?
On 5/27/20 1:00 PM, Elden W7LDN wrote:
Upon booting up the Pi... the dashboard shows that a connection
exists when it does not.
--
___________________________
73
n7tae (at) tearly (dot) net
|
Any D-Star reflector. It might be tied to a situation where the connection is not dropped via the command to do so. Like... rebooting the Pi with a connection active. I think I also had some weirdness happening when I issued a link command without unlinking. After doing that... when I did unlink... it told me I was still linked to the original reflector.
Update: Ok... I just went back and tested this. The first scenario is true. When one reboots with a D-Star/reflector connnection active... the connection still shows active after things come back up.
The second scenario is false. Doesn¡¯t happen. Because it clearly prevents me from linking anywhere if it¡¯s already linked.
|
Ok... I was able to reproduce my second scenario. I¡¯m sure you¡¯re asking, why would anyone do this???
But if I do reboot with an active connection to a D-Star reflector... the dashboard does think I¡¯m still linked when it comes back up. AND... if I do link to a different reflector and then unlink... it once again shows me as being connected to that original reflector it showed me connected to when it booted up.
|
Sorry Elden, I can't reproduce what you are seeing. If I link to XRF757 A, it shows that on my dashboard. If I then reboot my ZUMspot and it comes back up, the dashboard shows I'm not linked.? One of the first things QnetLink does when it starts it to automatically clear all linking information from the Sqlite3 database, so I'm not sure how that bogus linking information is surviving a reboot. Please double check you configuration to make sure that your module is not programmed to automatically link to a reflector upon boot up. (It's called "Link at startup" and is the first menu item in the configured module submenu.)
Another possibility is that somehow the database can no longer be opened with write permission. To check that, open a new terminal window and do "sudo journalctl -u qnlink -f" and then link and reboot you system and watch for database writing error message. If these occur, uninstall your system from the ./qnadmin tool. The uninstall should remove the damaged database, but just to be sure, you can exit qnadmin and do "sudo rm /usr/local/etc/qn.db". Then you can use ./qnadmin to reinstall you system.
Also, just to let everyone know, it is a feature of QnetLink that you can only link a module if it is currently unlinked.
|
It could be his browser caching this information and not refreshing correctly. Colby ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Tom Early Sent: Thursday, May 28, 2020 1:04 PM To: [email protected]Subject: Re: [QnetGateway] QnetGateway dashboard issue ? Sorry Elden, I can't reproduce what you are seeing. If I link to XRF757 A, it shows that on my dashboard. If I then reboot my ZUMspot and it comes back up, the dashboard shows I'm not linked.? One of the first things QnetLink does when it starts it to automatically clear all linking information from the Sqlite3 database, so I'm not sure how that bogus linking information is surviving a reboot. Please double check you configuration to make sure that your module is not programmed to automatically link to a reflector upon boot up. (It's called "Link at startup" and is the first menu item in the configured module submenu.)
Another possibility is that somehow the database can no longer be opened with write permission. To check that, open a new terminal window and do "sudo journalctl -u qnlink -f" and then link and reboot you system and watch for database writing error message. If these occur, uninstall your system from the ./qnadmin tool. The uninstall should remove the damaged database, but just to be sure, you can exit qnadmin and do "sudo rm /usr/local/etc/qn.db". Then you can use ./qnadmin to reinstall you system.
Also, just to let everyone know, it is a feature of QnetLink that you can only link a module if it is currently unlinked.
|
Good point Colby.. Have had that happen on other sites more times than I care to count.
"Nothing adds excitement like something that is none of your business" Note I am not a doctor, I don't even play one on television John F Davis
On Thursday, May 28, 2020, 01:07:55 PM EDT, Colby Ross W1BSB <colbypr@...> wrote:
It could be his browser caching this information and not refreshing correctly. Colby ? ?
From: [email protected] < [email protected]> On Behalf Of Tom Early Sent: Thursday, May 28, 2020 1:04 PM To: [email protected]Subject: Re: [QnetGateway] QnetGateway dashboard issue ? Sorry Elden, I can't reproduce what you are seeing. If I link to XRF757 A, it shows that on my dashboard. If I then reboot my ZUMspot and it comes back up, the dashboard shows I'm not linked.? One of the first things QnetLink does when it starts it to automatically clear all linking information from the Sqlite3 database, so I'm not sure how that bogus linking information is surviving a reboot. Please double check you configuration to make sure that your module is not programmed to automatically link to a reflector upon boot up. (It's called "Link at startup" and is the first menu item in the configured module submenu.)
Another possibility is that somehow the database can no longer be opened with write permission. To check that, open a new terminal window and do "sudo journalctl -u qnlink -f" and then link and reboot you system and watch for database writing error message. If these occur, uninstall your system from the ./qnadmin tool. The uninstall should remove the damaged database, but just to be sure, you can exit qnadmin and do "sudo rm /usr/local/etc/qn.db". Then you can use ./qnadmin to reinstall you system.
Also, just to let everyone know, it is a feature of QnetLink that you can only link a module if it is currently unlinked.
|
Yes, the bogus link status actually will survive multiple reboots. The only way I could get it to clear was to link to the reflector it mistakenly thought it was linked to... and then unlink. Then it would clear.
I uninstall and reinstall using the admin tool all the time. And I don¡¯t have anything set to link at startup. I will try your other suggestions and report back.
|
On Thu, May 28, 2020 at 10:07 AM, Colby Ross W1BSB wrote:
It could be his browser caching this information and not refreshing correctly.
I took all the recommended steps. Uninstalled, reinstalled. Checked that no auto connect was specified. This is still totally reproducible here. And to test the browser cache theory... after the browser was showing the bogus info... (after rebooting with an active connection)... I loaded the status page using a completely different computer. The invalid info was there. This tells me it¡¯s not a browser/cache problem. Here are the steps to reproduce... 1. make a connection to a D-Star reflector 2. load the dashboard in a browser 3. once the dashboard shows you connected... reboot the Pi 4. leave the dashboard page alone 5. once the system comes back up... the dashboard page will refresh by itself... showing the bogus info 6. the ¡°linked time¡± field will show a time span that goes back before the reboot 7. at this point... you can link to another reflector 8. when you unlink from that other reflector... it will again show the bogus link info Don¡¯t know what to tell you on this. Except I¡¯d suggest following these steps precisely. I¡¯ve run through these steps a number of times. All with the same result.
|
I am unable to reproduce. ?Once I rebooted my Pi after linking to something, the page eventually went to page cannot be displayed. It did not refresh from this point. I had to manually refresh, at which time, it said ¡°Unlinked¡± ? Colby ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Elden W7LDN Sent: Thursday, May 28, 2020 19:00 To: [email protected]Subject: Re: [QnetGateway] QnetGateway dashboard issue ? On Thu, May 28, 2020 at 10:07 AM, Colby Ross W1BSB wrote: It could be his browser caching this information and not refreshing correctly.
I took all the recommended steps. Uninstalled, reinstalled. Checked that no auto connect was specified. This is still totally reproducible here.
And to test the browser cache theory... after the browser was showing the bogus info... (after rebooting with an active connection)... I loaded the status page using a completely different computer. The invalid info was there. This tells me it¡¯s not a browser/cache problem.
Here are the steps to reproduce...
1. make a connection to a D-Star reflector
2. load the dashboard in a browser
3. once the dashboard shows you connected... reboot the Pi
4. leave the dashboard page alone
5. once the system comes back up... the dashboard page will refresh by itself... showing the bogus info
6. the ¡°linked time¡± field will show a time span that goes back before the reboot
7. at this point... you can link to another reflector
8. when you unlink from that other reflector... it will again show the bogus link info
Don¡¯t know what to tell you on this. Except I¡¯d suggest following these steps precisely. I¡¯ve run through these steps a number of times. All with the same result.
|
On Thu, May 28, 2020 at 04:20 PM, Colby Ross W1BSB wrote:
I am unable to reproduce. ?Once I rebooted my Pi after linking to something, the page eventually went to page cannot be displayed. It did not refresh from this point. I had to manually refresh, at which time, it said ¡°Unlinked¡±
?
Ok. Thanks for trying. Guess this is twilight zone territory.
|
For what it is worth I can also not reproduce.? ?I have the same results as Colby;
Rob VY1RG
On Thu, May 28, 2020 at 4:39 PM Elden W7LDN < w7ldn@...> wrote: On Thu, May 28, 2020 at 04:20 PM, Colby Ross W1BSB wrote:
I am unable to reproduce.? Once I rebooted my Pi after linking to something, the page eventually went to page cannot be displayed. It did not refresh from this point. I had to manually refresh, at which time, it said ¡°Unlinked¡±
?
Ok. Thanks for trying. Guess this is twilight zone territory.?
|
Seems odd... but the web browser that I¡¯m leaving open across the reboot... is on an iPad. The iPad web browser is umm... not exactly standard. I wonder if it¡¯s in any way possible that the QnetGateway software is loading any data from the cache of the browser? I mean otherwise... where would it be getting the data that is being displayed? This data is showing on a completely different computer on a browser that had never before loaded the dashboard web page.
?
|
To put it differently... perhaps leaving the browser open across the reboot would cause session variables to continue to live after the reboot. If the dashboard depends on session variables... perhaps... just a thought.
|
Okay, a couple of things: #5 in your process is not what I see. Both Safari on my mac and Firefox on my Linux laptop will timeout, both complaining about the unavailability of the Server soon after my ZUMspot starts the rebooting process. Both browser screens just display the "Server not found" error and neither ever refreshes when my ZUMspot is back, fully up and running. For your browser not to time out during the reboot process would mean that it's rebooting very quickly. Impossibly fast even.
For #6, the linked time is calculated by the query that the index.php file uses to extract data from the LINKSTATUS table in the /usr/local/etc/qn.db database. If it's showing the proper elapsed time since you originally linked (before the reboot), then that means either your system never rebooted or when it came back up, QnetLink was unable to clear that table in the database and you would see evidence of that in the qnlink log.
For #7 you didn't explicitly say, but I assume the webpage showed the proper link with the proper time as soon as you executed the link command. The #8 makes no sense because unlinking will clear the time, link and IP fields in the LINKSTATUS table. The only way it can be repopulated is with a linking command, it shouldn't ever go back to what it was before.
This is definitely "Twilight Zone" territory. It almost sounds like there's a phantom system running under your pi.
Finally, to address your question further down in this thread, there is no way data from a browser could end up back in the qn.db file. For one thing index.php opens the database read only, and all of the QnetGateway programs never connect to an HTTP stream.
|
Ah... I hadn¡¯t read this before we spoke today on the air. Very interesting. I feel the best shot of getting any problem fixed is getting it to where it can be reproduced. Virtually impossible to fix unless you can make it happen. I was totally planning on just forgetting about this. But considering the time and thought you put into it... I feel compelled to try to provide some useful info if I can. Particularly since I seem to be able to reproduce it here.
I will play with this a bunch more and see if I can glean any clues.
Debugging linux stuff isn¡¯t my forte. I guess my first question would be.... can I prevent the QnetGateway stuff from auto starting? Then I could examine the system after the reboot... but before the normal startup processes. Then possibly I could start things up manually, one step at a time.
|
Ok. There are apologies necessary here. In your prior instructions you mentioned viewing the qnlink log. I failed to catch that.? Here¡¯s what I found...
-- Logs begin at Fri 2020-05-29 21:09:12 PDT. --
May 29 21:09:24 zum2 qnlink[546]: CQnetDB::UpdateGW error: database is locked
|
On Fri, May 29, 2020 at 09:24 PM, Elden W7LDN wrote:
Ok. There are apologies necessary here. In your prior instructions you mentioned viewing the qnlink log. I failed to catch that.?
Here¡¯s what I found...
-- Logs begin at Fri 2020-05-29 21:09:12 PDT. --
May 29 21:09:24 zum2 qnlink[546]: CQnetDB::UpdateGW error: database is locked
However, I did proceed to take your recommended action to solve this problem by uninstalling and reinstalling things (way back in this thread). And the problem did remain. I could just wipe the whole deal and start with a fresh install of Raspbian.
?
|
On Fri, May 29, 2020 at 09:27 PM, Elden W7LDN wrote:
On Fri, May 29, 2020 at 09:24 PM, Elden W7LDN wrote:
Ok. There are apologies necessary here. In your prior instructions you mentioned viewing the qnlink log. I failed to catch that.?
Here¡¯s what I found...
-- Logs begin at Fri 2020-05-29 21:09:12 PDT. --
May 29 21:09:24 zum2 qnlink[546]: CQnetDB::UpdateGW error: database is locked
However, I did proceed to take your recommended action to solve this problem by uninstalling and reinstalling things (way back in this thread). And the problem did remain. I could just wipe the whole deal and start with a fresh install of Raspbian.
Gah... perhaps you¡¯re going to tell me that my tried and true method of restarting is not legit? I always do ¡°sudo shutdown -r now¡±. Can that cause this sort of problem?
|
The one possible thing I may have done to make this work...
I noticed that prior to the command that generated the error... the program loaded the reflector list. Thinking that a corrupted reflector list might have inadvertently left the database locked... I pulled a new one.
And I did a git reset. That didn¡¯t seem to do anything.?
|
Elden AI7HL
Tom Early