P88 casino login philippines.Enjoy Free 888+200 Daily Legal Bonus

Resolved slater91
(@slater91)

1 year, 11 months ago
Hello.
My website uses WordPress 6.1.1 and TotalUpkeep 1.15.4. I set up my home server so that it exposes an SFTP connection to my website’s server. I have set up the connection in the TotalUpkeep UI on my website, which validated the settings. The website is hosted on a VPS on DigitalOcean, so there are no limits imposed by the hosting company and I have complete control over the remote machine.

Unfortunately, the transfer always fails when managed by TotalUpkeep. Conversely, it works without issues when I manually initiate it using the SFTP command line on the remote server.
The logs include this:
```
[2022-12-08 03:10:01 UTC] Last error: Array
(
    [type] => 8
    [message] => Constant HDOM_SMARTY_AS_TEXT already defined
    [file] => /var/www/html/wp-content/plugins/responsive-lightbox/library/simplehtmldom/simple_html_dom.php
    [line] => 46
)

[2022-12-08 03:10:01 UTC] Cannot add signal handlers, pcntl_async_signals function does not exist.
```
Is there any way to work around this so the SFTP transfers work? While I could manage the transfers manually through a script, it would be less convenient than managing them through the TotalUpkeep interface.

Thank you!

Viewing 8 replies - 1 through 8 (of 8 total)

Plugin Contributor

(@weaponx13)

Hi –

Thanks for your question! I took a look at what you provided and the error that you included appears to be a notice which shouldn’t affect your ability to complete the SFTP transfer.

I believe that you indicated that the FTP/SFTP transfers don’t work at all from the plugin but just to make sure I’m getting you correctly does the FTP transfer work when you manually initiate it from the plugin? If it does and your issue is only affecting automated transfers and we can look into that deeper.

In the case that the transfer is not working even when you manually initiate it we might need some more info. If this is the case please provide us with the full upload log which can be found in your admin dashboard under Total Upkeep → Tools → Logs and you should see one titles look something like sftp-upload.log. If you can provide us the contents of that log we can review that for further issues.

Hopefully the contents of that log give us an idea of where the problem is coming from and please let us know if you have any additional questions for us while we work on this!

Thread Starter

slater91

(@slater91)

1 year, 11 months ago

Hello! Sorry for my late reply.

Things appear to have unexpectedly changed without me doing anything at all. FTP uploads started working all of a sudden, without me changing any settings on either the WordPress server nor the FTP server. The logs have the same error message, but the transfer seems to be completing just fine and files are uploaded to my FTP server.

The problem now is that sometimes the files are 0 B in size, and in general they are impossible to open – Ark, the utility provided by the KDE Plasma desktop on Linux to manage compressed archives, says that the archives are either not zip archives, or inconsistent.

This is the log from the last upload:

[2022-12-15 03:10:01 UTC] Last error: Array
(
[type] => 8
[message] => Constant HDOM_SMARTY_AS_TEXT already defined
[file] => /var/www/html/wp-content/plugins/responsive-lightbox/library/simplehtmldom/simple_html_dom.php
[line] => 46
)

[2022-12-15 03:10:01 UTC] Cannot add signal handlers, pcntl_async_signals function does not exist.
[2022-12-15 03:10:01 UTC] --------------------------------------------------------------------------------
[2022-12-15 03:10:01 UTC] Beginning Boldgrid_Backup_Admin_Ftp::upload…
[2022-12-15 03:10:01 UTC] Local path: /var/www/boldgrid_backup/boldgrid-backup-www.mywebsite.com-101eceba-20221215-030029.zip / 2775021730
[2022-12-15 03:10:01 UTC] Remote path: mywebsite/boldgrid-backup-www.mywebsite.com-101eceba-20221215-030029.zip
[2022-12-15 03:10:01 UTC] Connecting…
[2022-12-15 03:10:01 UTC] Logging in…
[2022-12-15 03:10:02 UTC] Beginning upload…
[2022-12-15 03:10:13 UTC] Last error: Array
(
[type] => 1024
[message] => Expected SSH_FXP_HANDLE or SSH_FXP_STATUS
[file] => /var/www/html/wp-content/plugins/boldgrid-backup/vendor/phpseclib/phpseclib/phpseclib/Net/SFTP.php
[line] => 2313
)

[2022-12-15 03:10:13 UTC] Upload status:

So it seems like the FTP session is opened, but then the file transfer doesn’t actually happen (which explains why this file is 0 B).

This is from a previous upload: it seems like for some reason there are multiple backup files which are concurrently uploaded and this might explain why the files are then inconsistent:

Let me know if you need more info. In the meantime, thanks for your help!

Thread Starter

slater91

(@slater91)

1 year, 11 months ago

Hello and happy holidays!

It looks like FTP uploading stopped working entirely (again). This applies to both automated and manual transfers. Here are the logs from the last two attempts (automated on the 25th, manual on the 26th):

[2022-12-25 03:10:01 UTC] Cannot add signal handlers, pcntl_async_signals function does not exist.
[2022-12-25 03:10:01 UTC] --------------------------------------------------------------------------------
[2022-12-25 03:10:01 UTC] Beginning Boldgrid_Backup_Admin_Ftp::upload...
[2022-12-25 03:10:01 UTC] Local path: /var/www/boldgrid_backup/boldgrid-backup-www.mywebsite.com-101eceba-20221225-030033.zip / 2767257684
[2022-12-25 03:10:01 UTC] Remote path: mywebsite/boldgrid-backup-www.mywebsite.com-101eceba-20221225-030033.zip
[2022-12-25 03:10:01 UTC] Connecting...
[2022-12-25 03:10:01 UTC] Logging in...
[2022-12-25 03:10:02 UTC] Beginning upload...
[2022-12-25 03:10:14 UTC] Last error: Array
(
    [type] => 1024
    [message] => Expected SSH_FXP_HANDLE or SSH_FXP_STATUS
    [file] => /var/www/html/wp-content/plugins/boldgrid-backup/vendor/phpseclib/phpseclib/phpseclib/Net/SFTP.php
    [line] => 2313
)

[2022-12-25 03:10:14 UTC] Upload status: 
[2022-12-26 11:29:26 UTC] Cannot add signal handlers, pcntl_async_signals function does not exist.
[2022-12-26 11:29:26 UTC] --------------------------------------------------------------------------------
[2022-12-26 11:29:26 UTC] Beginning Boldgrid_Backup_Admin_Ftp::upload...
[2022-12-26 11:29:26 UTC] Local path: /var/www/boldgrid_backup/boldgrid-backup-www.mywebsite.com-101eceba-20221225-030033.zip / 2767257684
[2022-12-26 11:29:26 UTC] Remote path: mywebsite/boldgrid-backup-www.mywebsite.com-101eceba-20221225-030033.zip
[2022-12-26 11:29:26 UTC] Connecting...
[2022-12-26 11:29:26 UTC] Logging in...
[2022-12-26 11:29:27 UTC] Beginning upload...

There’s nothing else on the 26th, although the UI did say “unable to upload backup file”. Looking at my FTP server’s logs, it seems like the issue does not lie with it as it’s the remote server which issues a disconnect seconds after starting (it’s very very similar with the manual transfer):

Dec 25 03:10:02 sr-backup sshd[11549]: Accepted password for user from 1.2.3.4 port 51698 ssh2
Dec 25 03:10:02 sr-backup sshd[11549]: pam_unix(sshd:session): session opened for user user(uid=1000) by (uid=0)
Dec 25 03:10:02 sr-backup systemd-logind[153]: New session 17107 of user user.
Dec 25 03:10:02 sr-backup systemd: pam_unix(systemd-user:session): session opened for 
user user(uid=1000) by (uid=0)
Dec 25 03:10:14 sr-backup sshd[11577]: Received disconnect from 1.2.3.4 port 51
698:11: 
Dec 25 03:10:14 sr-backup sshd[11577]: Disconnected from user user 1.2.3.4
port 51698
Dec 25 03:10:14 sr-backup sshd[11549]: pam_unix(sshd:session): session closed for user user

Any idea what might be happening here?

Plugin Contributor

Andy V

(@weaponx13)

1 year, 10 months ago

Hi –

Thanks for getting back to us! It sounds like there is a couple possibilities that could be causing this. I have couple more tests to help us narrow down what might be the specific cause.

The first thing that I would do is create a Sanity Check backup (https://www.boldgrid.com/support/total-upkeep/backup-wordpress-website/#sanity-check-backup) just to verify that backups are working at all on your website. There is a video at that link that demonstrates how to create a Sanity Check backup.

Next, we will need some additional information about the Total Upkeep configuration to see if we can get things working. Do you know which Compressor is used to generate backups on your website? You can check the Compressor settings under Total Upkeep > Settings > Backup Process in your WordPress admin. Changing the Compressor to System Zip might help with backup generation if it is not already selected there.

Let us know if the Sanity Check test works and if you are still having trouble please let us know and specify which compressor is being used or the options you have tried.

Thread Starter

slater91

(@slater91)

1 year, 10 months ago

Hello!
So, it looks like the issue with the .zip archives being unreadable was easily fixed by switching from ZipArchive to PclZip. Archives are now okay.

The issue now is that FTP upload keeps on being completely unreliable. I have backups set up twice a week and it worked for the last two occurrences, but today it stopped working again, with the same error as reported above.

Plugin Contributor

Andy V

(@weaponx13)

1 year, 10 months ago

Hi –

Thanks for getting back to us! I’m glad to hear that updating the compressor type fixed the issue with the archives being unreadable. Based on the logs you provided earlier and since you mentioned it does work some of the time, and that it always works when you do it via command line, I think we can rule out any issues on your remote server.

Since it’s intermittent like that, my guess is it might be a timeout, like PHP max_execution_time or possibly the timeout setting in either NGINX or Apache.

We can see in the logs that your PHP configuration doesn’t have process control functions enabled. There might be more info if you recompiled PHP to include those (https://www.php.net/manual/en/pcntl.installation.php), which would tell us if there was a kill signal (other than kill -9) from your actual server.

I hope this helps! Let us know if none of those changes work for you and we can take another look.

This reply was modified 1 year, 10 months ago by Andy V.

Thread Starter

slater91

(@slater91)

1 year, 10 months ago

Looking at configuration files, Apache’s timeout is 300 seconds (the default), whereas PHP’s max_execution_time is 60 seconds (double the default). Both seem okay to me, but do you have any advice on this?

As for recompiling PHP, I will try that when I have some more time as it is a bit of a daunting task.

Thanks for your help in the meantime.

Plugin Contributor

Andy V

(@weaponx13)

1 year, 10 months ago

Hi –

Thanks for getting back to us! The values that you have set should be fine in general, for PHP’s max_execution_time I typically recommend setting it to 120 seconds and 180 for heavier sites. You might bump that up and see if that helps. If not we may need to pursue getting process control functions enabled to hopefully get more detail on the errors.

I hope this helps! Let us know if none of those changes work for you and we can take another look.

Viewing 8 replies - 1 through 8 (of 8 total)

The topic ‘Upload to SFTP always fails’ is closed to new replies.