[Dxspider-support] export_user

[Dirk Koopman]

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.