[Dxspider-support] user_asc creation issue

[Brendan Minish]

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