[Dxspider-support] user_asc creation issue

[Dirk Koopman G1TLH]

A corrupt users.v3 basically. As to what causes that, we are looking at 
the reliability (or otherwise) of Berkeley DB. I have had ongoing 
problems with it since the beginning. Hence the provision of user_asc et al.

Usually the only way to deal with it is to take a working user_asc, have 
a scan through it to see that it's OK and regenerate from that. Then 
redo the export to check that it's still OK.

What I can say is that I have had some problems with the aftermath of 
PC41s coming in from other software having interpreted "national 
character sets" in their own individual way. It is conceivable that it 
is this that is causing some of the these problems.

There is a big problem here because there is no standard. I could easily 
enforce one, but the moment it drops that desperately wanted spot, I 
will get it in the neck (again).

If it were up to me I would insist on UTF8 and have done with it.

Dirk G1TLH

Brendan Minish wrote:
> It seems that it's looping over and over again between EA and DL 
> 
> it gets as far as EA3CUV then jumps back to DL2NEA, runs down the rest
> of the dls and EA's until it hits EA3CUV and repeats 
> 
> EA3CUV  bless( {qth => 'Tarragona',sort => 'U',name => 'juan carlos',call => 'EA3CUV',lastoper => '1252581557'}, 'DXUser' ) 
> DL2NEA  bless( {qth => 'Erlangen, Germany',lat => '49.5625',name => 'Bernd',qra => 'JN59MN',sort => 'U',homenode => 'DB0SPC-7',long => '11.0416666666667',call => 'DL2NEA',lastoper => '1118091126'}, 'DXUser' )
> 
> I went back to an older version, removed the above calls. deleted the
> users.v3 file, ran an import then ran an export and it ran fine 
> 
> looking at the above, have you any ideas as to what Might have caused
> the export script to loop?
> 
> 
> 73
> Brendan
> 
> 
> On Wed, 2009-09-16 at 13:26 +0100, Dirk Koopman G1TLH wrote:
>> This is a userfile corruption issue, which I have not experienced. 
>> However it seems to be caused by some kind of duff data.
>>
>> Have you looked at the generated user_asc? There are probably some (a 
>> lot) of repeated lines. You probably need to find the repeated callsigns 
>> in the non-expanded user_asc, delete those, regenerate the users.v3 file 
>> and see what happens.
>>
>> Dirk
>>
>> Or I go look...
>>
>> Brendan Minish wrote:
>>> hello 
>>>
>>> i am helping to mind a dxspider cluster and i have an issue where
>>> user_asc grows to the point where it fills the entire hard disk
>>> (normally it's got around 6.5G free space available)
>>>
>>> The cluster is running on centos 5.3 64bit and the host machine is an
>>> XEN virtual machine 
>>>
>>> Dxspider is running the latest build 
>>>
>>> this cluster was moved from another machine, whihc was running an old
>>> version of slackware (32 bit)  
>>>
>>> the move was done by git-pulling a new version, copying across the data
>>> and then running update_sysop.pl
>>>
>>> I have tried removing users.v3 and recreating the user database from an
>>> old (pre-migration ) copy of user_asc but the problem reoccurs. 
>>>
>>> the problem persists, how do I resolve &/or debug this issue, preferably
>>> whilst preserving the user database largely intact ? 
>>>
>>> the perl (&perl modules) and virtual machine configuration is identical
>>> to my own cluster (EI7MRE) which does not exhibit this issue 
>>>
>>
>> _______________________________________________
>> 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
>