<div dir="ltr"><font face="monospace">You have confirmed what I thought.<br>For a long time I have included in the spider startup this (although it is not always necessary):<br><br>cd /spider/local_data<br>perl user_json<br>cd /spider/perl<br>./<a href="http://update_sysop.pl">update_sysop.pl</a><br>./<a href="http://cluster.pl">cluster.pl</a><br><br>As for the crontab, I follow your advice to avoid problems.<br><br>The funny thing is that what happened to me this time, never happened to me in many tests. The user database was never corrupted.<br><br>Thank you very much for your clarifications, advice and great work.<br><br>73 de Kin</font><br><br><br>Translated with <a href="http://www.DeepL.com/Translator">www.DeepL.com/Translator</a> (free version)<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El vie, 7 ene 2022 a las 14:01, Dirk Koopman via Dxspider-support (<<a href="mailto:dxspider-support@tobit.co.uk">dxspider-support@tobit.co.uk</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <div>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/<a href="http://update_sysop.pl" target="_blank">update_sysop.pl</a> AFTER any perl user_json and BEFORE
      you start the new instance. <br>
      <br>
      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.<br>
      <br>
      Dirk<br>
      <br>
      On 07/01/2022 11:28, Joaquin . via Dxspider-support wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">You are a good guesser Dirk hihihi.<br>
        <br>
        What I have done is to try to raise a spider instance in a new
        container taking the files from these directories with me:<br>
        connect<br>
        local_cmd<br>
        local_data<br>
        scripts<br>
        filters<br>
        <br>
        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?<br>
        <br>
        Kin<br>
        <br>
        <br>
        Translated with <a href="http://www.DeepL.com/Translator" target="_blank">www.DeepL.com/Translator</a> (free
        version)<br>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">El vie, 7 ene 2022 a las
          11:58, Dirk Koopman via Dxspider-support (<<a href="mailto:dxspider-support@tobit.co.uk" target="_blank">dxspider-support@tobit.co.uk</a>>)
          escribió:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
          07/01/2022 10:13, Joaquin . via Dxspider-support wrote:<br>
          > Hi,<br>
          ><br>
          > Mojo build 413<br>
          ><br>
          > Initial status:<br>
          ><br>
          > -rw-rw-r-- 1 root root 5873539 Jun 30 2020 user_asc<br>
          > -rw-rw-r-- 1 root root 21710033 Jan 5 02:30 user_json.o<br>
          > -rw-rw-rw-r-- 1 root root root 20718747 Jan 4 00:20
          user_json.oo<br>
          > -rw-rw-r-- 1 root root root 19569522 Jan 2 08:17
          user_json.ooo<br>
          > -rw-rw-r-- 1 root root root 3496377 Jan 2 00:20
          user_json.oooo<br>
          > -rw-rw-rw-r-- 1 root root root 6691 Dec 31 00:20
          user_json.oooooo<br>
          > -rw-rw-rw-r-- 1 root root root 36483072 Jan 7 09:23
          users.v3j<br>
          ><br>
          > Note: I don't have any user_json on this node.<br>
          >       These files come from a node with Mojo build 331
          which has been <br>
          > up for 500 days.<br>
          <br>
          Please could you tell me what you want to do.<br>
          <br>
          But, guessing, I think you have created a new VM/docker image
          and tried <br>
          to populate it with an on old user_asc?<br>
          <br>
          To create a new instance from another one, I think this is the
          sequence:<br>
          <br>
          1. Clone the spider tree into the new image/machine or
          whatever.<br>
          2. Make sure DXVars.pm has any changes of callsign that you
          require for <br>
          this new image/machine.<br>
          3. Copy user_json (.o+ if necessary) from a recent
          export_users on a <br>
          known working image/machine.<br>
          4. perl user_json (.o+ if necessary)<br>
          5. /spider/perl/<a href="http://update_sysop.pl" rel="noreferrer" target="_blank">update_sysop.pl</a><br>
          6. Start the node.<br>
          <br>
          Try an export_user now.<br>
          <br>
          > I run from console: export_user<br>
          ><br>
          > I aborted it because it kept growing user_json and the
          CPU was loading <br>
          > up to 100%, this is what was in the /spider/local_data
          after aborting:<br>
          ><br>
          > -rw-rw-r-- 1 root root root 5873539 Jun 30 2020 user_asc<br>
          > -rw-rw-r-- 1 root root 872873984 Jan 7 09:26 user_json<br>
          > -rw-rw-rw-r-- 1 root root root 6691 Jan 7 09:23
          user_json.backstop<br>
          > -rw-rw-r-- 1 root root root 21710033 Jan 5 02:30
          user_json.oo<br>
          > -rw-rw-rw-r-- 1 root root root 20718747 Jan 4 00:20
          user_json.ooo<br>
          > -rw-rw-rw-r-- 1 root root root 19569522 Jan 2 08:17
          user_json.oooo<br>
          > -rw-rw-rw-r-- 1 root root root 3496377 Jan 2 00:20
          user_json.oooooo<br>
          > -rw-rw-rw-r-- 1 root root root 36483072 Jan 7 09:23
          users.v3j<br>
          ><br>
          > The solution is to find a .o backup with which this
          doesn't happen.<br>
          ><br>
          > Dirk, isn't there a way to protect the FS from fulling up
          to 100% and <br>
          > interrupting the export_user when the file gets so big
          that it gives a <br>
          > WARNING?<br>
          <br>
          No.<br>
          <br>
          <br>
          _______________________________________________<br>
          Dxspider-support mailing list<br>
          <a href="mailto:Dxspider-support@tobit.co.uk" target="_blank">Dxspider-support@tobit.co.uk</a><br>
          <a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" rel="noreferrer" target="_blank">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
Dxspider-support mailing list
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank">Dxspider-support@tobit.co.uk</a>
<a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" target="_blank">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a>
</pre>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>
Dxspider-support mailing list<br>
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank">Dxspider-support@tobit.co.uk</a><br>
<a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" rel="noreferrer" target="_blank">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a><br>
</blockquote></div>