[Dxspider-support] 1. Cluster started hanging several times a day. (David Spoelstra)

[Dirk Koopman]

As it happens, this has recently happened to GB7DJK as well. This is 
what I (eventually) did to fix it:

1. stop the node
2. cd /spider/data
3. rm users.v3 qsl.v1 dupefile
4. perl user_asc
5. ../perl/create_qsl.pl
6. restart the node

There is a long standing issue with DX_File databases (which are really 
Berkeley DB databases). These are notoriously finicky about only one 
writer and being closed properly. This is why there is a method of 
regenerating them. Now I don't know which of these got whacked (it's 
usually the dupefile) but it is also possible that some operating system 
system update  triggered it. I didn't discover which of them it was, but 
since I have done these things I appear to be running normally again.

As an aside, several years ago, I did try using sqllite3 databases as 
they seemed a possible way forward, but they turned out to be even more 
unreliable. Perhaps I ought to try again now that sqlite3 has become a 
sort of de facto standard for this sort of thing.

Dirk G1TLH

On 07/03/2019 15:32, David Spoelstra via Dxspider-support wrote:
> Keith, Andy, and Bernard: My RasPi3B is running off a hard drive. I 
> switched it to a hard drive when I replaced the RasPi2B with the 
> RasPi3 because of all the issues you mention.
>
> Bernard - it's not the power supply because the RasPi is still running 
> fine and I can do other things with it (abet slowly since the hung 
> spider process is taking so much CPU power). Also, I have this RasPi 
> and another hooked to a GOOD 5V 10A supply and the other RasPi isn't 
> having any problems. The spider process is just essentially dead since 
> it's sitting at about 100% CPU. I just kill the process and 
> immediately restart it and everything is fine for about another day.
>
> I just need some more data to debug it. Are there flags to turn on to 
> get more logs? Are there places to look I'm not looking (I've already 
> dug through syslog)?
>