Skip to main content

CPANEL-42530 - SSH Backup Error

Comments

46 comments

  • Darryl

    Seeing this error here too, accounts appear to be from a french reseller so likely using french locale.

    Going from 110.0.10 to 120.0.8

    pages of this kind of thing:

    [2024-05-23 14:43:40 +0100] The number of arguments to quant (6 in [quant,_1, bit, bits, bits, bits, bits, bits]) is incorrect (should be 2 for fr).
    [2024-05-23 14:43:40 +0100] The number of arguments to quant (6 in [quant,_1, bit, bits, bits, bits, bits, bits]) is incorrect (should be 2 for fr).
    [2024-05-23 14:43:40 +0100] The number of arguments to quant (6 in [quant,_2, bit, bits, bits, bits, bits, bits]) is incorrect (should be 2 for fr).
    [2024-05-23 14:43:40 +0100] The number of arguments to quant (6 in [quant,_1, bit, bits, bits, bits, bits, bits]) is incorrect (should be 2 for fr).
    [2024-05-23 14:43:40 +0100] Possible ambiguous use of trailing variable in output,url: [output,url,_1,documentation,target,_2,id,_3]
    [2024-05-23 14:43:40 +0100] Possible ambiguous use of trailing variable in output,url: [output,url,_1,_2,target,_3]
    [2024-05-23 14:43:40 +0100] Possible ambiguous use of trailing variable in output,url: [output,url,_1,documentation,target,_2,id,_3]
    [2024-05-23 14:43:40 +0100] Possible ambiguous use of trailing variable in output,url: [output,url,_1,documentation,target,_2,id,_3]
    [2024-05-23 14:43:40 +0100] Possible ambiguous use of trailing variable in output,url: [output,url,_1,documentation,target,_2,id,_3]
    [2024-05-23 14:43:40 +0100] Possible ambiguous use of trailing variable in output,url: [output,url,_1,documentation,target,_2,id,_3]
    [2024-05-23 14:43:40 +0100] Possible ambiguous use of trailing variable in output,url: [output,url,_1,How to Authenticate Your Server,target,_2]
    [2024-05-23 14:43:40 +0100] Possible ambiguous use of trailing variable in output,url: [output,url,_1,spamassassin.apache.org,id,_2]
    [2024-05-23 14:43:40 +0100] The number of arguments to quant (6 in [quant,_2,thread de restauration,threads de restauration,threads de restauration,threads de restauration,threads de restauration,threads de restauration]) is incorrect (should be 2 for fr).
    [2024-05-23 14:43:40 +0100] The number of arguments to quant (6 in [quant,_2,thread de transfert,threads de transfert,threads de transfert,threads de transfert,threads de transfert,threads de transfert]) is incorrect (should be 2 for fr).

     

    0
  • AzeDK

    isn't the solution to mass change all cpanel accounts to English locale before using Transfer Tool?

    0
  • Rodrigo Arija

    Hello! It could be for the transfers; I'll give it a try. However, the issue isn't just with transfers, but also with backups. The same problem appears in the logs, making it very difficult to debug these errors along with the real ones. Visibility is lost, and the transfers always end with a WARNING status.

    It's incredible that, after so many years, this language compatibility bug hasn't been resolved. I've opened tickets about it, but nothing has been done.

    Do you know anything about this,  cPRex ?

    0
  • cPRex Jurassic Moderator

    Let me poke the team about this one again next week, as I know I won't find out anything useful over a weekend.

    0
  • cPRex Jurassic Moderator

    I did reach out to the team today and it sounds like we're just going to suppress these errors since they don't ultimately matter for the successful completely of the backups or transfers.  I can't say when exactly this is happening, but at least there's some progress.

    1
  • cPRex Jurassic Moderator

    UPDATE - I see the team is testing a fix in version 124.  It's not even out of testing yet, but I just wanted to let everyone know this is getting some action.  I'll post know as soon as I hear more on my end.

    2
  • cPRex Jurassic Moderator

    UPDATE - this is resolved in version 124 and will be included in all future releases of that version.  I haven't heard about any backports to 122 or 120 at this time.

    0
  • rhm.geerts

    Sorry to bump this thread, but I'm having the issue when importing accounts from an old server to a brand new server with the transfer tool.
    New server is using 124.0.17

    Old server we're logging in to from the new server with the transfer tool has 110.0.49.

    But we need to transfer these urgently.

    0
  • Rodrigo Arija

    Hi, if the errors you're seeing are the same as those mentioned earlier in the post, you can safely ignore them and proceed with the import.

    0
  • rhm.geerts

    I don't know if they are all the same. I got a lot of these:
    [2024-12-06 02:07:45 +0100] The number of arguments to quant (6 in [quant,_1,bit,bits,bits,bits,bits,bits]) is incorrect (should be 2 for nl). 

    and these:

    [2024-12-06 02:07:45 +0100] Possible ambiguous use of trailing variable in output,url: [output,url,_1,documentation,target,_2,id,_3]
    [2024-12-06 02:07:45 +0100] Possible ambiguous use of trailing variable in output,url: [output,url,_1,_2,target,_3]

    Kindlike as the first one:
    [2024-12-06 02:07:45 +0100] The number of arguments to quant (6 in [quant,_2,thread herstellen,threads herstellen,threads herstellen,threads herstellen,threads herstellen,threads herstellen]) is incorrect (should be 2 for nl).
    [2024-12-06 02:07:45 +0100] The number of arguments to quant (6 in [quant,_2,thread overdragen,threads overdragen,threads overdragen,threads overdragen,threads overdragen,threads overdragen]) is incorrect (should be 2 for nl).

    It's a very long list.
     
    But 24 other errors too:
    • [2024-12-06 02:38:53 +0100] warn [Internal Warning while parsing [stdin] 5842] Cpanel::Async::WebSocket::Courier=HASH(0x9f2ed00): DESTROY()ed without closing!
    • at /usr/local/cpanel/Cpanel/Async/WebSocket/Courier.pm line 554.
    • Cpanel::Async::WebSocket::Courier::DESTROY(Cpanel::Async::WebSocket::Courier=HASH(0x9f2ed00)) called at /usr/local/cpanel/Whostmgr/Transfers/Session.pm line 741
    • eval {...} called at /usr/local/cpanel/Whostmgr/Transfers/Session.pm line 741
    • Whostmgr::Transfers::Session::_create_current_item(Whostmgr::Transfers::Session=HASH(0x425fde0), HASH(0x44bbe48), HASH(0x9f48768)) called at /usr/local/cpanel/Whostmgr/Transfers/Session.pm line 613
    • Whostmgr::Transfers::Session::__ANON__() called at /usr/local/cpanel/3rdparty/perl/536/cpanel-lib/Try/Tiny.pm line 100
    • eval {...} called at /usr/local/cpanel/3rdparty/perl/536/cpanel-lib/Try/Tiny.pm line 91
    • Try::Tiny::try(CODE(0xc7581a8), Try::Tiny::Catch=REF(0x44c4038)) called at /usr/local/cpanel/Whostmgr/Transfers/Session.pm line 624
    • Whostmgr::Transfers::Session::_prime_next_queue_item(Whostmgr::Transfers::Session=HASH(0x425fde0), "RESTORE", "AccountRemoteRoot", HASH(0x9f48768)) called at /usr/local/cpanel/Whostmgr/Transfers/Session.pm line 562
    • Whostmgr::Transfers::Session::dequeue_next_item(Whostmgr::Transfers::Session=HASH(0x425fde0), "RESTORE") called at /usr/local/cpanel/Whostmgr/Transfers/Session/Processor.pm line 551
    • Whostmgr::Transfers::Session::Processor::_process_items(Whostmgr::Transfers::Session::Processor=HASH(0x4318f68)) called at /usr/local/cpanel/Whostmgr/Transfers/Session/Processor.pm line 508
    • Whostmgr::Transfers::Session::Processor::__ANON__() called at /usr/local/cpanel/Cpanel/ForkAsync.pm line 72
    • eval {...} called at /usr/local/cpanel/Cpanel/ForkAsync.pm line 72
    • Cpanel::ForkAsync::do_in_child(CODE(0x43ee438)) called at /usr/local/cpanel/Whostmgr/Transfers/Session/Processor.pm line 510
    • Whostmgr::Transfers::Session::Processor::_spawn_child(Whostmgr::Transfers::Session::Processor=HASH(0x4318f68), undef, Whostmgr::Transfers::Session=HASH(0x425fde0)) called at /usr/local/cpanel/Whostmgr/Transfers/Session/Processor.pm line 292
    • Whostmgr::Transfers::Session::Processor::_process_child(Whostmgr::Transfers::Session::Processor=HASH(0x4318f68), Whostmgr::Transfers::Session=HASH(0x425fde0), 0) called at /usr/local/cpanel/Whostmgr/Transfers/Session/Processor.pm line 240
    • Whostmgr::Transfers::Session::Processor::_process_child_with_output_redirection(Whostmgr::Transfers::Session::Processor=HASH(0x4318f68), Whostmgr::Transfers::Session=HASH(0x425fde0), 0, "serverdalocomhcopya20241206010644LUc") called at /usr/local/cpanel/Whostmgr/Transfers/Session/Processor.pm line 205
    • Whostmgr::Transfers::Session::Processor::__ANON__() called at /usr/local/cpanel/Cpanel/ForkAsync.pm line 72
    • eval {...} called at /usr/local/cpanel/Cpanel/ForkAsync.pm line 72
    • Cpanel::ForkAsync::do_in_child(CODE(0x42f0d90)) called at /usr/local/cpanel/Whostmgr/Transfers/Session/Processor.pm line 207
    • Whostmgr::Transfers::Session::Processor::start(Whostmgr::Transfers::Session::Processor=HASH(0x4318f68)) called at bin/start_transfer.pl line 57
    • main::__ANON__() called at /usr/local/cpanel/3rdparty/perl/536/cpanel-lib/Try/Tiny.pm line 100
    • eval {...} called at /usr/local/cpanel/3rdparty/perl/536/cpanel-lib/Try/Tiny.pm line 91
    • Try::Tiny::try(CODE(0x425fcd8), Try::Tiny::Catch=REF(0x261f868)) called at bin/start_transfer.pl line 72

    So at least the last ones I don't think are safe to ignore.

    0
  • Kent Brockman

    @rhm.geerts: Unless the errors mention difficulties provisioning disk space, errors locating DNS or data transfer issues, you can safely ignore the large list of notifications. They are due to inconsistencies between the old cPanel and the new one. The newest cPanel will try to reset old incompatible things, so that your account will be alright. 

    0
  • rhm.geerts

    Thank you both.

    But what about the 24 other ones. These differ from the rest here. Do I need to create a new thread for those?

    And 1 other question. If I start the whole account transfer again. Will it skipp things which are already done and only do what might be missing? Or will it overwrite everything?

    0
  • Kent Brockman

    It will overwrite everything. The whole process will be done again.

    I can only suggest you to open a ticket mentioning this thread and see what they can tell. Afterwards please let us know the outcome :-)

    0
  • rhm.geerts

    Unfortunately opening a ticket seems not possible anymore in this new version if the license is not bought directly from cPanel. We got it together with our server from Hetzner.

    0
  • cPRex Jurassic Moderator

    You should be able to create a ticket with your license provider, and then they would escalate the issue to us directly if they are not able to resolve it.

    1
  • rhm.geerts

    Thank you. I just do the transfer again. If the 24 errors happen again then I will send in a ticket.

    If not then I now know I can ignore the other errors.

     

    1

Please sign in to leave a comment.