[Dxspider-support] export_user

[Joaquin .]

You have confirmed what I thought.
For a long time I have included in the spider startup this (although it is
not always necessary):

cd /spider/local_data
perl user_json
cd /spider/perl
./update_sysop.pl
./cluster.pl

As for the crontab, I follow your advice to avoid problems.

The funny thing is that what happened to me this time, never happened to me
in many tests. The user database was never corrupted.

Thank you very much for your clarifications, advice and great work.

73 de Kin


Translated with www.DeepL.com/Translator (free version)

El vie, 7 ene 2022 a las 14:01, Dirk Koopman via Dxspider-support (<
dxspider-support at tobit.co.uk>) escribió:

> The short answer to your last question is "yes". This is why you have to
> change /spider/local/DXVars.pm to a different $mycall and $myalias and then
> run /spider/perl/update_sysop.pl AFTER any perl user_json and BEFORE you
> start the new instance.
>
> I would also suggest renaming your /spider/local_cmd/crontab before
> starting as well. You can then copy what need across from the old crontab
> at your leisure.
>
> Dirk
>
> On 07/01/2022 11:28, Joaquin . via Dxspider-support wrote:
>
> You are a good guesser Dirk hihihi.
>
> What I have done is to try to raise a spider instance in a new container
> taking the files from these directories with me:
> connect
> local_cmd
> local_data
> scripts
> filters
>
> One question I have is if $mycall is different from the $mycall I used
> with the files I exported, can this prove problems, or in other words, does
> the user_json file have any info that relates it to the $mycall of the
> source cluster?
>
> Kin
>
>
> Translated with www.DeepL.com/Translator (free version)
>
> El vie, 7 ene 2022 a las 11:58, Dirk Koopman via Dxspider-support (<
> dxspider-support at tobit.co.uk>) escribió:
>
>> On 07/01/2022 10:13, Joaquin . via Dxspider-support wrote:
>> > Hi,
>> >
>> > Mojo build 413
>> >
>> > Initial status:
>> >
>> > -rw-rw-r-- 1 root root 5873539 Jun 30 2020 user_asc
>> > -rw-rw-r-- 1 root root 21710033 Jan 5 02:30 user_json.o
>> > -rw-rw-rw-r-- 1 root root root 20718747 Jan 4 00:20 user_json.oo
>> > -rw-rw-r-- 1 root root root 19569522 Jan 2 08:17 user_json.ooo
>> > -rw-rw-r-- 1 root root root 3496377 Jan 2 00:20 user_json.oooo
>> > -rw-rw-rw-r-- 1 root root root 6691 Dec 31 00:20 user_json.oooooo
>> > -rw-rw-rw-r-- 1 root root root 36483072 Jan 7 09:23 users.v3j
>> >
>> > Note: I don't have any user_json on this node.
>> >       These files come from a node with Mojo build 331 which has been
>> > up for 500 days.
>>
>> Please could you tell me what you want to do.
>>
>> But, guessing, I think you have created a new VM/docker image and tried
>> to populate it with an on old user_asc?
>>
>> To create a new instance from another one, I think this is the sequence:
>>
>> 1. Clone the spider tree into the new image/machine or whatever.
>> 2. Make sure DXVars.pm has any changes of callsign that you require for
>> this new image/machine.
>> 3. Copy user_json (.o+ if necessary) from a recent export_users on a
>> known working image/machine.
>> 4. perl user_json (.o+ if necessary)
>> 5. /spider/perl/update_sysop.pl
>> 6. Start the node.
>>
>> Try an export_user now.
>>
>> > I run from console: export_user
>> >
>> > I aborted it because it kept growing user_json and the CPU was loading
>> > up to 100%, this is what was in the /spider/local_data after aborting:
>> >
>> > -rw-rw-r-- 1 root root root 5873539 Jun 30 2020 user_asc
>> > -rw-rw-r-- 1 root root 872873984 Jan 7 09:26 user_json
>> > -rw-rw-rw-r-- 1 root root root 6691 Jan 7 09:23 user_json.backstop
>> > -rw-rw-r-- 1 root root root 21710033 Jan 5 02:30 user_json.oo
>> > -rw-rw-rw-r-- 1 root root root 20718747 Jan 4 00:20 user_json.ooo
>> > -rw-rw-rw-r-- 1 root root root 19569522 Jan 2 08:17 user_json.oooo
>> > -rw-rw-rw-r-- 1 root root root 3496377 Jan 2 00:20 user_json.oooooo
>> > -rw-rw-rw-r-- 1 root root root 36483072 Jan 7 09:23 users.v3j
>> >
>> > The solution is to find a .o backup with which this doesn't happen.
>> >
>> > Dirk, isn't there a way to protect the FS from fulling up to 100% and
>> > interrupting the export_user when the file gets so big that it gives a
>> > WARNING?
>>
>> No.
>>
>>
>> _______________________________________________
>> Dxspider-support mailing list
>> Dxspider-support at tobit.co.uk
>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>
>
> _______________________________________________
> Dxspider-support mailing listDxspider-support at tobit.co.ukhttps://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20220107/01f4aed4/attachment.htm>