Manual Version update from 6.0.6 directly to 6.7.2

Alex

Pratik However, the etc/php/8.4/fpm/pool.d/shilaalekh.org.conf did not have correct permission and was under root:root which as per your instruction we changed to tskuser:www-data as shown below:

No, no, no... the conf file needs to be set with root:root as you had it. You need to open the conf file and look the user and group properties.

nano shilaalekh.org.conf

; RPM: apache Choosed to be able to access some dir as httpd
user = tskuser

; RPM: Keep a group allowed to write in log dir.
group = www-data

; Note: This value is mandatory.
listen = 127.0.0.1:9001

It could be little different. as listed, etc.

Pratik It currently resides within shilaleekh directory in the same level of httpdocs directory, did you mean it was wrong or is that okay ?

They have to be on the same level, it's fine.

Pratik Regarding your instruction to ensure apache vhosts needs to point to httpdocs, we noticed previously the .conf file was pointing to httpdocs/dedalo which now we changed to only httpdocs, before/after screenshots as follows

Yes, Apache scope needs to point to the httpdocs directory instead dedalo one, so it is now pointed correctly, but, the ProxyPass needs a / at the end of the path:

ProxyPass fcgi://127.0.0.1:9001/home/www/vhosts/shilaalech/httpdocs/

Note: you can see the typical directory tree here

Best

Pratik

Thank you Alex. we implemented the suggested change. Reverted privilege to root:root for the conf file, added the missing / on proxy path and verified directory hierarchy as suggested.

Also, went a step further to ensure memory limits in php8.4 ini file was same/increased like that of (older)php8.3, however,
the issue still persists and the update process still throws 'max retries reached' error

Screenshots presented as follows:
Front-end application error after clicking update:

Browser inspect error screenshot on the same page:

Apache Error Log Screenshot:

I do wonder, when we check the systemctl status php8.4fpm-service , 8.4 is the one that is running, however the server log is showing errors associated with 8.3, does this have something to do with the problem we are facing ?

Kindly let me know if there are any further measures/recommendation that we can try or if you think we have exhausted all options in which case we might need online support session as per your convenience.

Best Regards,

PaCo

Hi @Pratik

The Dédalo API uses a recovery mechanism for network failures.
However, it seems that the data manager request cannot connect anyway to the master server via the PHP server.

1.- Verify the master code URL is accessible from the server:

https://master.dedalo.dev/dedalo/code/6/6.7/6.7.0_dedalo.zip

(I have checked it and it is working correctly now accessing from Spain).

For example:

You can use wget:

wget --spider https://master.dedalo.dev/dedalo/code/6/6.7/6.7.0_dedalo.zip

or you can use curl:

curl -o /dev/null -w "%{http_code}" https://master.dedalo.dev/dedalo/code/6/6.7/6.7.0_dedalo.zip

(Expected CURL output: 200)

2.- Double check the PHP error log in the server for additional info about the problem.
Is usually defined in /var/log/php-fpm/error.log or /var/log/php/php-errors.log or search error log directive in init file as grep error_log /etc/php/8.4/fpm/php.ini.

3.- Why do you want to perform a 'clean' update instead of an 'incremental' one?

Best

Pratik

PaCo Thanks for the quick reply Paco.
1.
Verification of the master code URL gave 200 status as expected.

var/log/php-fpm directory are empty , same is the case with /etc/php/8.4/fpm this directory does not exist, a similar directory exists showcased as follows:

var/log/apche2/error.log showcased as below

Based on your suggestion we tried the incremental approach as well, which also results in the same "max tries reached" error as in the clean case. Also, in previous version upgrades , while updating from 6.3 to 6.4 incremental got stuck infinite loop while clean successfully updated to 6.4 and ever since we have been upgrading using the clean option.

Thank you. Look forward to further insights on resolving this.

Best Regards,

Alex

Pratik var/log/php-fpm directory are empty , same is the case with /etc/php/8.4/fpm this directory does not exist, a similar directory exists showcased as follows:

Sorry a Paco's mistake about the php error log.

You need to see the PHP-FPM error log, usually it will be in the Dédalo's home at the same level than httpdocs in a log directory. You can see the path at the PHP pool: /etc/php/8.4/fpm/pool.d/shilaalekh.org.conf and the param will be something as:

php_admin_value[error_log] = /home/www/vhosts/shilaalekh.org/logs/php_error_log

If you locate the error log file, you can set a tail to see the error in this way:

tail -f /home/www/vhosts/shilaalekh.org/logs/php_error_log

then, go back to the browser and reproduce the error and you will see in the terminal the error.

Best

Pratik

Alex @PaCo No worries, Thanks again to the both of you. Sure I shall try this suggested approach as well, please let me get back on this tomorrow as I do not have access to the server now due to timing reasons. Shall keep you posted.

Best Regards,

Pratik

Alex Good morning, All right, we checked the php error log based on your recommended path.
Then hit the update process while monitoring the tail -f in terminal.
At first it resulted in unable to download curl error and when trying again it gave the same error from last time "max retries reached"
Below is the relevant screenshots from the process, any suggestion will be much appreciated.
On first try

Now it shows the previous error of max tries reached. below is the php error log screenshot:

Best Regards,

Pratik

To resolve the previous php error log we increased the memory limit in php.ini file , rebooted the server for the .ini file to take effect an re-ran the update process, only to get the old "move dir failed" issue. Below is the most recent error log screenshot:

Based on the move command fail, we checked the privileges and user group for the folder location as shown in error but it is already set as tskuser:www-data , please advise if we need to make any further adjustment based on the above error log. Folder privilege screenshot as below:

Best Regards,

Alex

Pratik

Hi Pratik

You can run the command in the terminal using the PHP user defined in the PHP pool file: /etc/php/8.4/fpm/pool.d/shilaalekh.org.conf

1 Switch the user to the PHP pool user (it should be tskuser):

su tskuser

2 copy the command in the error log and run it.

mv /home/www/vhosts/shilaalekh.org/backups/code/dedalo_6.6.5_2025-10-17_015243/media /home/www/vhosts/shilaalekh.org/httpdocs/dedalo_code/media

And see if you have a error in the terminal.

Best

PaCo

Hi @Pratik

The error is from CURL in the line 470 of core_functions.php

// execute post
$result = curl_exec($ch);

With the error information, as we see, PHP has only 128 MB of memory assigned.
This value is too low, the minimum recommended is 8 GB that you can set in php.ini file.

; Maximum amount of memory a script may consume (8192MB)
; For 8GB, use 8192M
memory_limit = 8192M

Pratik

PaCo Thank you, Yes paco we noticed that and increased the memory size after which the memory limit error went away but we got 'Move dir failed' error as highlighted in my previous(most recent) post.

Pratik

Alex We got a directory not empty error Alex.

Shall we try manually deleting the directory and moving the directory or running the update ?

Alex

Ok, seems that you move the media directory or the update was not finished and the ./media directory was created but not filled and now is not possible to move it.

First, check if the /media directory in the /httpdocs/dedalo/media/ has media files. You can see the size of the directory:

cd ./httpdocs/dedalo/media
du -sh media

1.- If the media is empty, you can delete it.
2.- if the media is NOT empty, some files was moved, some files not, so, you need to recreate the media directory manually, moving the files that are not copied.

OPTION

If you have a previous copy of all. replace the dedalo_code and try to update the process with this previous copy.

Best

Pratik

Thank you so much alex and paco. After all your suggestions and series of hit and trial with folder privileges and issues with local and media directory we were finally able to successfully update the application to the latest 6.7.4 version and the application is now stable. (workaround finally worked by creating empty local directory manually and same for the media directory so mv command could bring files with no issues)

However, even in the latest version, we could not find the features we were looking for - auto translation and custom field addition. I shall create a separate thread for those issues.

Many thanks again for all your prompt responses.

Alex

😀🎉🎉🎉🎊🍾🍾🥳

Best