Failed database update v 4.0.1

[Gambalunga]

▶ Reproduction steps

1. Update from v.3.20.19 to 4.0.1
2. open website go to Notices click on Update (database)
3. Update fails
4. Try to run CLI update from cPanel Terminal
5. Update fails (see error message below)

😢 Unexpected result

From notice Update the site responds:


When running the command from terminal:

[mycom@c03 [~]]# public_html/app/bin/legacy -C update
Chevere\Throwable\Exceptions\ErrorException thrown in /home2/mycom/public_html/app/src/Legacy/functions.php:975

# Message [Code #2]
session_start(): open(/opt/alt/php81/var/lib/php/session/sess_c3tfh20d6cgh9rbagmpgd2msc8, O_RDWR) failed: No such file or directory (2)

# Incident ID:634697670ddbf

# Time
2022-10-12T10:31:03+00:00 [1665570663]

# Stack trace
------------------------------------------------------------
#0 /home2/mycom/public_html/app/src/Legacy/functions.php:975
{main}()
------------------------------------------------------------
#1 /home2/mycom/public_html/app/src/Legacy/functions.php:975
session_start()
------------------------------------------------------------
#2 /home2/mycom/public_html/app/legacy/entrypoints/cli.php:53
Chevereto\Legacy\loaderHandler()
------------------------------------------------------------
#3 /home2/mycom/public_html/app/bin/legacy:13
require_once(string(length=58))
------------------------------------------------------------

# Server
Linux c03.tmdcloud.london 3.10.0-962.3.2.lve1.5.67.el7.x86_64 #1 SMP Fri Mar 25 07:13:21 UTC 2022 x86_64

** "mycom" is not the real domain name.

📃 Error log message
error log attached.
It should be noted that I deleted the vendor directory as mentioned in "Hot fixes" and then tried to unpack the zipped file in the server file manager but something did not work. I then unzipped the file locally and uploaded all the files to the server. After that I was able to access the site.

NB. Site has now been reverted to v 3.20.19

 

[Gambalunga]

A list of the actual SQL commands that are required for the database updates would be usefull. This would allow the updates to be manually performed.

 

[Gambalunga]

I have continued to attempt the upgrade to 4.0.1 but despite all efforts I still get the same error.

In the docs referring to CLI https://v4-docs.chevereto.com/application/reference/cli.html#installapp/bin/legacy

There is a warning "Don't run as root
The Chevereto console won't work when using root user. It must be called from a normal user."

This does not make it clear unless one understands what is meant by "root user". My site is hosted on a shared server and the opening of a Terminal window opens in the user's root directory. I tried change directory to that in which the Chevereto script is installed; I first entered "cd public_html" but unfortunately that made nod difference.

It seems the CLI functions want to open a file "/opt/alt/php81/var/lib/php/session/sess_iv7nk4ngdm5f1f16l3f8a6cm78, O_RDWR" where "sess_iv7nk4ngdm5f1f16l3f8a6cm78, O_RDWR" is a variable file name.

In fact the directory /opt/alt/php81/var/lib/php/session/ does not seem to exist at all, let alone the "sess" file.

The following is the commands that I ran in Terminal and the result.

[tmimgcom@c03 [~]]# cd public_html
[tmimgcom@c03 [~/public_html]]# app/bin/legacy -C update
Chevere\Throwable\Exceptions\ErrorException thrown in /home2/tmimgcom/public_html/app/src/Legacy/functions.php:975

# Message [Code #2]
session_start(): open(/opt/alt/php81/var/lib/php/session/sess_iv7nk4ngdm5f1f16l3f8a6cm78, O_RDWR) failed: No such file or directory (2)

# Incident ID:634d233d48791

# Time
2022-10-17T09:41:17+00:00 [1665999677]

# Stack trace
------------------------------------------------------------
#0 /home2/tmimgcom/public_html/app/src/Legacy/functions.php:975
{main}()
------------------------------------------------------------
#1 /home2/tmimgcom/public_html/app/src/Legacy/functions.php:975
session_start()
------------------------------------------------------------
#2 /home2/tmimgcom/public_html/app/legacy/entrypoints/cli.php:53
Chevereto\Legacy\loaderHandler()
------------------------------------------------------------
#3 /home2/tmimgcom/public_html/app/bin/legacy:13
require_once(string(length=58))
------------------------------------------------------------

# Server
Linux c03.tmdcloud.london 3.10.0-962.3.2.lve1.5.67.el7.x86_64 #1 SMP Fri Mar 25 07:13:21 UTC 2022 x86_64

 

[Rodolfo]

# Message [Code #2] session_start(): open(/opt/alt/php81/var/lib/php/session/sess_c3tfh20d6cgh9rbagmpgd2msc8, O_RDWR) failed: No such file or directory (2)

When running from CLI the session should't be handled, in such context theres no need for session. In any case, if CLI can't write to sessions then is likely that it won't work when using HTTP. This is somehow common in cPanel setups as the PHP ini config rarely updates the location of the session dir on PHP version switch and you end up with permissions issues.

If you can't fix the system session path permissions you may want to use another directory (make sure that the user running PHP has rw permissions there): https://v4-docs.chevereto.com/application/configuration/environment.html#session-variables

A list of the actual SQL commands that are required for the database updates would be usefull. This would allow the updates to be manually performed.

This is already provided: https://v4-admin.chevereto.com/settings/system.html#dump-update-query

This does not make it clear unless one understands what is meant by "root user".

Refer to the CLI documentation: https://v4-docs.chevereto.com/application/reference/cli.html

 

[Gambalunga]

When running from CLI the session should't be handled, in such context theres no need for session. In any case, if CLI can't write to sessions then is likely that it won't work when using HTTP. This is somehow common in cPanel setups as the PHP ini config rarely updates the location of the session dir on PHP version switch and you end up with permissions issues.

Thank you for your reply

I think the session issue may be causing some problems (not only in the update) and I am working on this problem. Thank you for bringing it to my attention.

In the mean time, in order to run the CLI database update, and if the session should not be handled in the CLI context, would it be possible to simply remove the line in the php which is causing this problem?

 

[Gambalunga]

When running from CLI the session should't be handled, in such context theres no need for session. In any case, if CLI can't write to sessions then is likely that it won't work when using HTTP. This is somehow common in cPanel setups as the PHP ini config rarely updates the location of the session dir on PHP version switch and you end up with permissions issues.

If you can't fix the system session path permissions you may want to use another directory (make sure that the user running PHP has rw permissions there): https://v4-docs.chevereto.com/application/configuration/environment.html#session-variables

It seems that most, if not all, of the problems that I have been having in the last couple of weeks have been because of conflicts in the location of the session variable. Once that was sorted out in the control panel PHP options (has to be re-set on changing PHP versions) the CLI database update worked perfectly.

MultiPHP was possibly creating problems with the ini files that are not required if PHP selector however I also set the path in the cPanel MultiPHP editor.

Resolving this issue may also have resolved the problems that I was having with the login under Windows 11 as I am now not having problems.