Manual Version update from 6.0.6 directly to 6.7.2

Pratik

Hi Paco, we were able to revert back to 6.6.5 using the code backup and get the application interface running.

We made sure all folders had correct user and group permissions as per your suggestion and also cleared the browser content cache along with rebooting apache, system and server itself.
Then ontology update worked just fine, but when we try updating the code to 6.7.0 with clean update, application throws the same 'move local dir failed' message, causing to wipe the dedalo folder and application crashing to 404 and throwable API error as mentioned in last post.

Below are the screenshots of the folder privileges/permissions along with the error received.

We have yet again reverted the application using the backup to 6.6.5 but are unable to successfully update to 6.7.0. The php error log did not show any useful information. I agree with you remarks that this is likely due to folder permission issue but as shown in screenshots we've set all folders to 755 and correct user permission to our knowledge. Please point out if you notice any errors on our end. Any suggestion is much appreciated.

Best Regards,

Alex

Hi Pratik

Can you see the permissions inside the backups directory?
Clean update will move the old code from ./httpdocs/dedalo to ./bakcups/code directory.

And check the PHP pool user (/etc/php/8.4/fmp/pool.d/my_pool.conf). It needs to be the owner of your host, in your case: tskuser
In other words, PHP user and group needs to be the same than GNU/Linux user.

user = tskuser
group = www-data

Note: backups directory is at the same level of httpdocs directory, it needs to be outside Apache scope (Apache vhosts needs to point to httpdocs), but, inside the GNU/Linux and PHP Dédalo user scope.

Best

Pratik

Hi again, thank you for your response. Yes Alex, the permissions inside the backups directory have permissions set for the intended user, screenshot as follows:

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:

Also, I am a bit confused regarding the note you sent suggesting the backups directory location to be outside Apache scope. It currently resides within shilaleekh directory in the same level of httpdocs directory, did you mean it was wrong or is that okay ?
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
BEFORE:

AFTER:

After all these changes when we tried the update code process again, we were met with a new error saying "max retries reached request failed" as shown in screenshot below

Also, we have both php 8.3 and 8.4, we also tried using 8.3 which would cause the initial problem of "move dir failed" while using 8.4 we got the above new error with max retries reached. We have made permission changes to the pool file in both versions as per your instruction.

Open to further suggestions to resolve this problem ahead.

Best Regards,

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