A lot of “proces control” errors in the logs
-
I can create a backup (and transfer it to the local machine), but there are some issues:
- backup is stored on the web server, while this option was not selected;
- FTP storage fails with “Unable to create backup directory on remote host”, while my FTP client can do so, with exactly the same credentials;
- All logs contain a lot of messages “Cannot add signal handlers, pcntl_async_signals function does not exist.” It was suggested in other bug reports to enable process control, but this seems to be the case here:
pi@pi4:/var/www/html/wp-content $ php -i | grep pcntl
pcntl
pcntl support => enabled
Furthermore, I don’t find any reference to pcntl in the php.ini files. - The file size of my backup is reported as “File size: -25329934 B“.
-
About the negative file size (on Raspberry Pi-4): this bug report may be helpful.
Hi @softpol
Sorry to hear you’re experiencing some issues restoring your Total Upkeep backup. I think the first thing we need to do is confirm that you are attempting to restore a backup from a Total Upkeep backup file onto your local machine, is that correct?
My next questions is have restorations ever fully worked at the destination site or is this your first time attempting to restore a backup? If you can provide the full restoration log for us to review we can take a deeper look into what’s causing the issue. To do so, visit the destination website and navigate to?Total Upkeep > Tools > Logs?and look for the log with a filename similar to restore-XXXXXXXX.log and a timestamp corresponding to the restoration that failed.
You can also check to see if your website passes the functionality tests in the?Preflight Check tool.
You mentioned the “Cannot add signal handlers, pcntl_async_signals function does not exist” It sounds like the?
pcntl_async_signals
?method is not enabled in the version of PHP currently running on your web server and enabling it should get rid of the error message. You might need to reach out to your hosting provider to see if that is something that they can handle for you.Backup Stored on the Web Server
In some instances in order for your remote backup to complete Total Upkeep must first create the backup on your web server so that it can be transferred to Drive.
This particular backup has to be created on the web server but you can set the retention to 1 one ensure that multiple backups are not being stored but in this case there’s no way to actually transfer the backup to your remote destination without first taking it on the web server.
If backups are being saved on the server despite not selecting this option, it could be due to a default setting or an issue with the configuration. Double-check the backup settings in Total Upkeep:
- Go to Total Upkeep > Settings in your WordPress dashboard.
- Ensure that the option to store backups locally (on your web server) is unchecked if you don’t want backups stored there. Adjust other destination settings accordingly.
FTP Storage Issue
The error message about failing to create a backup directory on the remote host can occur due to several reasons. Here’s how to troubleshoot:
- Permissions: Ensure the FTP user has the necessary permissions to create directories and write files. Some servers require specific permissions for these actions.
- Directory Path: Verify the path you are trying to write to. Ensure it is correct and the directory exists, or the FTP user has permission to create it.
- Passive Mode: Check if your FTP requires passive mode and ensure it’s enabled in the Total Upkeep FTP settings.
I encourage you to create a new forum topic on our support site so that we can better assist you with this and moderate any personal website information that may be revealed in your logs.
Thank you
Thanks for the prompt feedback. I am actually not restoring a backup. The reported issues popped up during the backup process.
FTP “passive” mode is enabled in the settings. I changed it to “auto”, but it reverts automatically to “passive”. And now, there is even no attempt anymore to start an FTP session (nor is there an https://ftp.log). The option to store backups locally (on my web server) is unchecked and FTP/SFTP is checked.
The “preflight check” shows PASS.
I changed the retention to 1 and I now have exactly one backup on the web server (the web server suffered from “disk full” yesterday, because every backup attempt consumed 4GB…).
PHP is installed from the sury.org repository (Debian flavour) and I am pretty sure that it supports process control.
Any ideas about the negative file size of the backup?
Hey @softpol
My apologies, I assumed that you were attempting to restore the backup on your local machine. In that case we’d like to take a look at your latest backup log if that’s possible.
You mentioned that the backup did complete. If that’s the case you should have a log of this file as well. You can find it in?Total Upkeep > Tools > Logs. If you could provide that log we can get a idea of exactly what’s happening.
As for your issue with FTP there a many scenarios that could cause this. You definitely want to ensure that any firewall or security modules within your hosting environment are not blocking requests from your WordPress installation to the FTP server. Also review the following:
1. Check FTP Settings in Total Upkeep
- Connection Type: Make sure the connection type (FTP or SFTP) matches what your FTP client uses.
- Path Format: Verify the format of the directory path. Sometimes, paths need to be absolute rather than relative, or vice versa.
2. Permissions and Path
- Permissions: Ensure that the FTP user has the necessary permissions to create directories and write files in the specified path.
- Directory Path: Double-check the directory path you are trying to write to. Ensure it exists or that the user has permissions to create it if it does not.
You should note that some servers have restrictions on scripts creating or modifying files via FTP, especially in managed WordPress hosting environments. Check with your hosting provider if there are such restrictions.
File Size Concern – When encountering a negative file size in a backup reported by Total Upkeep, it usually indicates an issue with the backup process, such as a failure to accurately calculate the size of the files included in the backup. This could be due to various factors including file system errors, permissions issues, or software bugs.
To address this issue, you’ll want to ensure that Total Upkeep has the necessary permissions to access and back up all files on your server. Try running the backup process again to see if the errors persists. Sometimes, transient server or software issues can cause a one-time problem.
The good news is we know backups can work on the server. Once we get a look at your backup logs we’ll be able to help you determine the best path forward.
Thanks @softpol, we hope to hear back from you soon.
Meanwhile, I discovered that FTP fails, because the user enters at the top folder, where he has no access rights. It is however not possible to define a path to the folder with write rights, because only letters, numbers, dashes, and underscores are allowed.
My web server runs on Debian-bookworm and I am pretty sure that the installed php-version supports proces control (as shown in my first message).
Did you check this bug report, concerning the negative file size? It may be helpful…
Hi @softpol,
I do understand what you’re saying about not having the ability to define a path to the folder with write rights to establish your FTP connection. I’m going to run this by out developers as we may need more information since Total Upkeep is has not been rigorously tested with your Debian-bookworm environment. Based on what you’re describing the issue with the FTP access rights and the inability to set a specific directory path in Total Upkeep due to character restrictions seems like a limitation or bug in the plugin’s FTP handling mechanism. Normally, paths should allow slashes to specify directories within the FTP server’s file structure.
As a temporary workaround, you might consider adjusting the FTP user’s root directory within the FTP server’s settings to directly point to the directory where you have write access. This can sometimes be configured through your hosting control panel or by contacting your hosting provider.
To further inspect the negative file size one thing you can do is run a “Sanity Check Backup” – which is only backing up .txt files, to make sure the backup process can complete successfully. If it does complete, this helps to further indicate a possible server intervention.
Here are the steps to run a Sanity Check Backup:
- From the inside of your Total Upkeep dashboard click the Backup Site Now button.
- Under Files and Folders type
*.txt
into the Includes input. This ensures that only .txt files will be included in the backup. - Under Database exclude all database tables.
- Click Backup Site Now.
After running your “Sanity Check Backup” visit the “Tools” section of your Total Upkeep dashboard, click Logs and view your last log to confirm that it completed and note the file size.
Thanks for continuing to work through this with us @softpol!
The FTP server is configured with a number of “shares”. A new FTP session is shown the shares that are accessible for that account, so the first thing to do is to “cd” in the wanted share or to target a <share>/folder. That’s not possible with this plugin, because it literally says “A folder in your FTP/SFTP server to store your backups, will be created if it doesn’t exist. Please only use letters, numbers, dashes, and underscores.”.
Anyway, not a big problem as I can transfer local copy of the backup manually from the web server to the FTP server.
This is the log of the “sanity check backup”:
[2024-05-12 18:21:10 UTC] Cannot add signal handlers, pcntl_async_signals function does not exist. [2024-05-12 18:21:10 UTC] Backup process initialized. [2024-05-12 18:21:10 UTC] Cannot add signal handlers, pcntl_async_signals function does not exist. [2024-05-12 18:21:10 UTC] Backup process initialized. [2024-05-12 18:21:10 UTC] Process id: 9402 [2024-05-12 18:21:10 UTC] Backup triggered by: xxx ([email protected]) [2024-05-12 18:21:10 UTC] -------------------------------------------------------------------------------- [2024-05-12 18:21:10 UTC] Starting dump of database… [2024-05-12 18:21:10 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7163984 (6,83 MB) / 8664864 (8 MB) [2024-05-12 18:21:10 UTC] No database tables selected to backup. A database export will not be in this backup. [2024-05-12 18:21:10 UTC] Dump of database complete! $status = 1 [2024-05-12 18:21:10 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7324192 (6,98 MB) / 8664864 (8 MB) [2024-05-12 18:21:10 UTC] -------------------------------------------------------------------------------- [2024-05-12 18:21:10 UTC] Retrieving file list. [2024-05-12 18:21:23 UTC] Cannot add signal handlers, pcntl_async_signals function does not exist. [2024-05-12 18:21:23 UTC] Backup process running: Yes (pgid = 521) [2024-05-12 18:21:26 UTC] Retrieving backup directory. [2024-05-12 18:21:26 UTC] Adding Database to file list. [2024-05-12 18:21:26 UTC] Starting archiving of files. Chosen compressor: system_zip [2024-05-12 18:21:26 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7440936 (7,10 MB) / 20208456 (19 MB) [2024-05-12 18:21:27 UTC] Starting to create list of files to include in zip. [2024-05-12 18:21:27 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7267048 (6,93 MB) / 20208456 (19 MB) [2024-05-12 18:21:27 UTC] Finished creating list of files to include in zip. 245 files in zip. [2024-05-12 18:21:27 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7304976 (6,97 MB) / 20208456 (19 MB) [2024-05-12 18:21:27 UTC] Starting to close the zip file. [2024-05-12 18:21:27 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7267480 (6,93 MB) / 20208456 (19 MB) [2024-05-12 18:21:28 UTC] Chunk closed in 0.91224098205566 seconds. 100% complete closing [2024-05-12 18:21:28 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7275928 (6,94 MB) / 20208456 (19 MB) [2024-05-12 18:21:28 UTC] Finished closing the zip file. [2024-05-12 18:21:28 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7267400 (6,93 MB) / 20208456 (19 MB) [2024-05-12 18:21:28 UTC] Starting to add db dump to the zip file. [2024-05-12 18:21:28 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7267400 (6,93 MB) / 20208456 (19 MB) [2024-05-12 18:21:28 UTC] Finished adding db dump to the zip file. [2024-05-12 18:21:28 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7267400 (6,93 MB) / 20208456 (19 MB) [2024-05-12 18:21:28 UTC] Archiving of files complete! [2024-05-12 18:21:28 UTC] Archive filepath / size: /var/www/html/wp-content/boldgrid_backup_O8iL9XKdK2mT/boldgrid-backup-www.softpol.net-a5b7ba1e-20240512-182126.zip / 808553 (789,60 KB) [2024-05-12 18:21:28 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7267400 (6,93 MB) / 20208456 (19 MB) [2024-05-12 18:21:28 UTC] Starting sending of email… [2024-05-12 18:21:28 UTC] Cannot add signal handlers, pcntl_async_signals function does not exist. [2024-05-12 18:21:28 UTC] Backup process running: Yes (pgid = 521) [2024-05-12 18:21:28 UTC] Sending of email complete! Status: 1 [2024-05-12 18:21:28 UTC] Backup complete! [2024-05-12 18:21:28 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7398072 (7,06 MB) / 20208456 (19 MB) [2024-05-12 18:21:28 UTC] Backup complete! [2024-05-12 18:21:28 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 7264688 (6,93 MB) / 20208456 (19 MB) [2024-05-12 18:21:33 UTC] Cannot add signal handlers, pcntl_async_signals function does not exist. [2024-05-12 18:21:33 UTC] Backup process running: Yes (pgid = 521)
and this is the content of the mail, I received after completion:
Backup details:
Estimated Pause: 0.03 seconds
Duration: 17.35 seconds
Total size: 1.99 MB
Archive file path: /var/www/html/wp-content/boldgrid_backup_O8iL9XKdK2mT/boldgrid-backup-www.softpol.net-a5b7ba1e-20240512-182126.zip
Archive file size: 789.60 KB
Compressor used: system_zip
Backup triggered by: xxx ([email protected])FILE AND FOLDER SETTINGS
Included: *.txt
Excluded:DATABASE SETTINGS
Tables Excluded:?<a lot of stuff follows>
Hey @softpol,
Happy to hear you at least have a way to download and transfer the backup files. So it looks like the backup did complete and we do have the correct file size for the Sanity Check backup file. Maybe try running another backup and if you still have issues with the negative file size enable File List Analysis and try running the full backup again.
Navigate to?Total Upkeep > Settings > Backup Process. If System Zip is available, choose that option. System Zip is significantly faster than the PclZip or ZipArchive libraries, and may use fewer resources. Check the box to enable the?Filelist Analysis and attempt to create another backup using the?Default?compression level.
This message below looks like a warning so I don’t think it’s causing any direct issues with the backup
Cannot add signal handlers, pcntl_async_signals function does not exist.
I hope this helps.
I did a backup with “file list analysis”, as you suggested. The filelist.log does not show any anomalies.
The file size in the backup overview is -25290772 B.
The archive.log mentions: “[2024-05-15 07:06:01 UTC] Archive filepath / size: /var/www/html/wp-content/boldgrid_backup_O8iL9XKdK2mT/boldgrid-backup-www.softpol.net-a5b7ba1e-20240515-060732.zip / -25290772 ()“
Linux sees the file as: “-rw——- 1 www-data www-data 4,0G 15 mei 09:06 boldgrid-backup-www.softpol.net-a5b7ba1e-20240515-060732.zip”
The mail, I received after completion, says “Total size: 4.33 GB”.
Hi @softpol,
I think in the end this is going to have to do with how the backup file is interacting with your specific Linux environment. I’m going to consult with our developers on this and see what they suggest. For further assistance you can reach out to our direct support channel.
Thank you
FYI: this website is running on a Raspberry Pi-4. The CPU is of the type aarch64, but the OS is 32-bit Debian. I am afraid that you store the file size in an “int” type variable, with PHP_INT_MAX = 2147483647, while the size of the backup is 4269676524.
That’s why I pointed you already two weeks ago to another bug report, where casting on an int variable returned a negative free space value.
Hi @softpol
Thank you for continuing to work with us.
I’ve discussed your concerns with our development team, and we truly appreciate your detailed feedback regarding the backup process, particularly on the Raspberry Pi-4 environment with a 32-bit Debian OS.
Ensuring compatibility across different platforms and setups is a priority for us, though we must also consider the broader user base when allocating resources for enhancements. Unfortunately, due to the relatively small number of users utilizing the plugin on Raspberry Pi devices, addressing the specific intricacies of this platform may not be feasible at this time.
Nevertheless, your feedback is incredibly valuable to us, and we’re keeping it in mind for future updates and improvements. We’ve created a bug ticket for this issue on GitHub, so please feel free to follow along for updates. Our goal is to provide a seamless experience for all users, and your input helps us work towards that.
If you have any further questions or concerns, please feel free to reach out. We greatly appreciate your ongoing support and look forward to continuing to serve you better in the future.
OK, let’s close this topic. Thanks for your time and effort.
I cannot remember why I installed a 32-bit OS on this machine. I am considering to move the website to another machine with a 64-bit OS (if I ever have time…). That will most probably solve the problem.
You’re very welcome @softpol and we appreciate you for taking the time to work with us! Moving your website to a machine with a 64-bit OS may indeed help resolve the issue with negative file sizes in backups.
If you ever have any other questions for us don’t hesitate to reach back out. We’re always here to help!
- The topic ‘A lot of “proces control” errors in the logs’ is closed to new replies.