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

[Michael Carper, Ph.D.]

I'm presently pulling the latest cty.dat and usdbraw files automatically...
and it loads them automatically.

Linux puzzles me.

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

> This really sounds like a file corruption problem. I would start by
> getting the latest tarball and overwriting all of the distribution files.
> Then set the file permissions, types and ownership as per the installation
> instructions. I would then go back a couple of revisions of user_asc.oo and
> rebuild it. Then get the latest cty.dat and usdbraw, rebuild and load
> those. If that doesn't cure it, then I don't know what will.
>
> Mike, W1NR
>
> On 03/31/2016 08:24 AM, Michael Carper, Ph.D. wrote:
>
>> 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
>> <mailto: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>
>>         <mailto: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>
>>         <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>
>>         <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>
>>         <mailto: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
>>         <mailto:Dxspider-support at dxcluster.org>
>>         http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>
>>
>>     _______________________________________________
>>     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/908078e1/attachment-0001.html>