transfersite issues, mailing list exists

When doing a Stage 0 transfer, the transfer fails with the following error.
foo@bar.com isn’t on any mailing list, but this has happened for a couple of accounts that have mailing lists and I can’t see any reason why…

Reason: Mailing list already exists

         0. SoapClient->__call("majordomo_create_mailing_list", ["news", "1SzYDbMbFIaafivl", "foo@bar.com", "domain.com"])
            [/usr/local/apnscp/lib/Util/API.php:86]
         1. Util_API->__call("majordomo_create_mailing_list", ["news", "1SzYDbMbFIaafivl", "foo@bar.com", "domain.com"])
            [/usr/local/apnscp/lib/CLI/Transfer.php:238]
         2. CLI_Transfer->_sync("remote", "majordomo_create_mailing_list", "news", "1SzYDbMbFIaafivl", "foo@bar.com", "domain.com")
            [/usr/local/apnscp/lib/CLI/Transfer.php:253]
         3. CLI_Transfer->_sync("remote", "majordomo_create_mailing_list", "news", "1SzYDbMbFIaafivl", "foo@bar.com", "domain.com")
            [/usr/local/apnscp/lib/CLI/Transfer.php:253]
         4. CLI_Transfer->_sync("remote", "majordomo_create_mailing_list", "news", "1SzYDbMbFIaafivl", "foo@bar.com", "domain.com")
            [/usr/local/apnscp/lib/CLI/Transfer.php:253]
         5. CLI_Transfer->_sync("remote", "majordomo_create_mailing_list", "news", "1SzYDbMbFIaafivl", "foo@bar.com", "domain.com")
            [/usr/local/apnscp/lib/CLI/Transfer.php:253]
         6. CLI_Transfer->_sync("remote", "majordomo_create_mailing_list", "news", "1SzYDbMbFIaafivl", "foo@bar.com", "domain.com")
            [/usr/local/apnscp/lib/CLI/Transfer.php:253]
         7. CLI_Transfer->_sync("remote", "majordomo_create_mailing_list", "news", "1SzYDbMbFIaafivl", "foo@bar.com", "domain.com")
            [/usr/local/apnscp/lib/CLI/Transfer.php:1202]
         8. CLI_Transfer->_sync_mailing_lists()
            [/usr/local/apnscp/lib/CLI/Transfer.php:172]
         9. CLI_Transfer->process()
            [/usr/local/apnscp/bin/scripts/transfersite.php:233]


array (
)

To be clear, domain.com is my redaction, foo@bar.com is literal from the error message.

This value is a placeholder that gets replaced when the files are transferred over. The error occurs because /var/lib/majordomo/lists/news.config exists on the target server but no corresponding file named /var/lib/majordomo/lists/news exists on the new server so majordomo:list-mailing-lists doesn’t report it on the new server.

To fix, delete news.config on the new server.

Why is this happening to numerous accounts?
Is it copying the file and then failing out of confusion?
/var/lib/majordomo/ doesn’t even exist on source or destination What’s the actual path then if that’s the issue?

Why is this happening to numerous accounts?

I don’t know.

What’s the actual path then if that’s the issue?

/var/lib/majordomo within the vfs as mentioned.

Ok, so Stage 0 is a new transfer, how can that file both not exist and exist and cause the transfer to fail? I can delete the account on the new server, transfer again and it fails for the same reason.

What else can I provide you?

how can that file both not exist and exist and cause the transfer to fail?

I’m reading the code. That’s how the check works.

Here’s the breakdown, which is the origin of the error on the receiving side. To fix, delete news.config on the new server (or delete the site on the new server), then reapply migration.

Refs

In effect stat /home/virtual/siteXX/fst/var/lib/majordomo/lists/news.config reports the file exists, which is what PHP’s file_exists() method call is a wrapper for.

The account doesn’t exist on the new server, I do a transfer at STAGE 0 and it fails with that error.
How can I delete a file or account that doesn’t exist?

I understand what you’re saying, but it’s impossible for the file to exist if it’s a new transfer of an account that never existed on the server. Even after the failed transfer, I delete the site on the new server and try again and it still fails.

There’s something else going on with the check / transfer process.

I would check your invocation of the migration script and that the target server - as resolved by DNS - is not the same machine as the destination. There’s no way you can progress to migration that late if the site does not exist on the target server.

env DEBUG=1 /usr/local/apnscp/bin/scripts/transfersite.php --server=newserver.lithium.hosting --stage=0 site

And yes, it resolves, its not new it’s an existing server I’m moving some accounts to. The account gets created on the new server but the migration fails. This is not a DNS issue or a script invocation issue. All other accounts succeed without issue, the only accounts that fail are with mailing lists.

If you’re confident this is a bug in the quality of the code you can pull a silver support ticket via my.apiscp.com. If this is a warranty issue arising from the quality of the product - and not configuration of your environment - then the support fee would be reimbursed.

This is not something I’ve seen especially if the site does not exist on the target server as API client creation would fail.

I’ll hopefully have time by this weekend to look further into it.

1 Like