[Dxspider-support] R: R: R: I: Problem shutdown dxspider?

[ik5pwj at gmail.com]

Hi Dirk,

I don't think it was a Storable corruption problem because the SSD disk is the same as the one that lasted for 5 years without crashes or irremediable problems.

In fact, the SSD disk was replaced a month ago with an identical new one where I installed from debian version 8, to debian 9 and then to the last debian 10, also adding 1 gigabit of ram for a total of 2 gigabit.

 

After I installed version 157 and I have to say that for 3.4 weeks the spider software had never gone down.

 

Then it happened for the first time and I thought about a memory problem.

 

In the last week he has crashed several times going the dxspider down without starting again.

This also happened to IW5ECF-6 which had a couple of crashes going into shutdwn the dxspider despite having the 155/210 version

 

Today I double-checked everything and fixed the rights of the directories as also indicated for the first installation of the software.

 

This after following all the steps you indicated.

 

Now let's see what happens .....

 

Thank you

73 Alex ik5pwj.

 

 

Da: Dxspider-support <dxspider-support-bounces at tobit.co.uk> Per conto di Dirk Koopman via Dxspider-support
Inviato: domenica 21 giugno 2020 23:28
A: Alex via Dxspider-support <dxspider-support at tobit.co.uk>
Cc: Dirk Koopman <djk at tobit.co.uk>
Oggetto: Re: [Dxspider-support] R: R: I: Problem shutdown dxspider?

 


On 21/06/2020 21:25, Alex via Dxspider-support wrote:

However I ran "git checkout mojo" and with

  git branch i see again

 

   master

* mojo

 

with out newsusers

 

How come I don't even see     newusers     on the list?

What did I do wrong?

 


I have looked at the history (gitk --all) and  I think that I understand why there is a 'convert-users-v3-to-v4.pl' in this branch, but it should not do anything that would affect a 'mojo' branch version of  the code or affect the node in any way. The 'mojo' branch code doesn't access the users.v4 file. What is more likely is that you have been struck by a Storable corruption - which I am now seeing much more on RPi nodes - as the SD Cards that most people use wear out after six months or so. 

Fairly soon, I am going to do a users file change. That code is rather better tested and reliable - unlike the experimental "newusers" branch which attempted to remove DB_File as well as Storable. As soon as I am happy with and issued the RBN code, I shall be merging the new version of the users file (users.v3j) which is exactly the same format and usage as users.v3 but using JSON instead of Storable as the serialisation code.

To explain: it is not possible to store the (binary) internal user records directly to disk, they have to be "serialised" (or "frozen") before they are stored. To access a user record, I get it from the disk and then "unserialiase" (or thaw) it before I can use it in code. Up until recently, this was done by the standard perl module Storable, but it has caused a number of errors over the years and is unusably unreliable with subcommands (commands that run in forked copies of the node - like sh/dx).

But I will merge that work when I am satisfied that the RBN code is stable enough for general testing. 

If anyone is interested to see the work in progress, login to gb7djk.dxcluster.net 7300 and do a 'set/wantrbn'. You are advised to also do an:

  accept/rbn by_zone 14 and not zone 14 or zone 14 and not by_zone 14

replacing the '14' with your cq zone. This will a) cut down on the spots that you receive and b) only show you spots where the skimmer or spotted call is in your zone and the other is not. No spots from the skimmers for calls in the same zone :-) 

In the info you might see something like:

CW  24dB Q:8*+ Z:14,15 
           ^^^
           ||+-- Respotted - means that it has been seen for at least one hour and is a repeat (once / hour)
           |+--- * means that the skimmer could not agree on the frequency, the one shown is the majority opinion.
           |     This is distressingly common. I have seen discrepancies of 600Hz! 
           +---- The "quality" 1-9. This is count of skimmers (max 9) that have spotted this call. If this is > 1 then the
                 spot call is likely not to be "busted".

The Z:14:15 is a list of cq zones that the spotting skimmers are in. If you have no filters then this list does not include the skimmer on the spot. Also, again if you don't have filters, then skimmer call and the dB figure is the lowest one seen (if Q: > 1). If you do have a filter then the spot shown will be the most "relevant" one. 

73 Dirk G1TLH

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20200622/dacf26f5/attachment-0001.htm>