[Dxspider-support] DXSpider on CentOS 7.x?

[Michael Carper, Ph.D.]

No.  I'm not quite sure how to get there.  But this whole thing is
happening very regularly now.

Using the "top" command in Linux, I can see spider spike the CPU when this
happens.  Dunno.

Mike, WA9PIE

On Thu, Mar 31, 2016 at 5:01 AM, Mike McCarthy, W1NR <lists at w1nr.net> wrote:

> Have you looked at the console output and found where it hangs? One thing
> that can take a considerable amount of time and blocks all other activity
> are database search commands like 'show/dx somerarecall' and 'show/log
> someunknowncall'. If your spots go back a long time or your logs then that
> would account for some of it. However, I have never seen it cause a restart.
>
> Mike, W1NR
>
> On 03/30/2016 11:51 PM, Michael Carper, Ph.D. wrote:
>
>> This evening... I had about an hour of regular disconnects for users...
>> watched the server processor hit 70%... eventually, the node restarted
>> completely... meanwhile, the server was not restarted.
>>
>> I will not have much hair soon... I'm gonna pull it out.
>>
>> Mike, WA9PIE
>>
>> On Tue, Mar 29, 2016 at 4:57 PM, Dirk Koopman <djk at tobit.co.uk
>> <mailto:djk at tobit.co.uk>> wrote:
>>
>>     On 29/03/16 22:10, Michael Carper, Ph.D. wrote:
>>
>>         Hmmm... that occurred to me also (which is the way I normally do
>>         this with Windows servers).
>>
>>         Is there no more to the exercise except copying the /spider tree
>>         over?  (ie. I'm not really a "Linux guy")
>>
>>
>>
>>     Not normally. There may be an issue with the user, usdb and qsl data
>>     files because of incompatibilities between different versions of
>>     Berkeley database file formats and/or Storable versions. But, to a
>>     large extent, these are now a thing of the past. But if you need to:
>>     the first two can be easily regenerated (from the user_asc and
>>     pretending to do an "update" for usdb), the "live data" qsl info
>>     that is collected automatically can be regenerated using
>>     /spider/perl/create_qsl.pl <http://create_qsl.pl>. If you have many
>>     spots, it can take a while - I have been collecting them since 1997
>> :-).
>>
>>     If you have the two machines side by side and there a network
>>     connection, the easiest way to replicate is to login as the "sysop"
>>     user to the new box then:
>>
>>     $ cd /spider
>>     $ rsync -avz sysop at oldbox:/spider/* .
>>
>>     When you try start cluster.pl <http://cluster.pl> you will probably
>>     find that there are packages that you have forgotten to load (I
>>     always do anyway). Just load the missing packages and, with a
>>     following wind, it should all just spring into life.
>>
>>
>>     _______________________________________________
>>     Dxspider-support mailing list
>>     Dxspider-support at dxcluster.org <mailto:Dxspider-support at dxcluster.org
>> >
>>     http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>
>>
>>
>>
>> _______________________________________________
>> Dxspider-support mailing list
>> Dxspider-support at dxcluster.org
>> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>
>>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20160331/f898248b/attachment.html>