@maybeageek
Please open an own thread with all details. I think your problem differs from the problem in this thread.
e.g. that’s 2 min. in Debian 9.
-
to run:
wget -O - https://www.liveconfig.com/liveconfig.key | apt-key add - -
edit apt/source.list:
deb [arch=amd64] http://repo.liveconfig.com/debian/ stretch php -
install own PHP
apt-get install php-7.3-opt-ldap php-7.3-opt-apcu php-7.3-opt-imagick php-7.3-opt-ioncube php-7.3-opt-redis -
Adjust settings like php.ini if necessary, /opt/php-7.3/etc
-
(e.g. file_uploads = On)
-
Add PHP Handler to Plesk
-
run:
/usr/local/psa/bin/php_handler --add -displayname “7.3 custom” -path /opt/php-7.3/bin/php-cgi -clipath /opt/php-7.3/bin/php-cgi -phpini /opt/php-7.3/etc -type fastcgi -id “PHP7.3_custom”
1 Like
With Debian Buster 10 there are no problems with the php-version. Perhaps you dist-upgrade to Debian Buster 10. Debian Buster 10 was released more than a year ago.
Debian Stretch 9 has only LTS support.
I tried nextcloud-18.0.7 with php-7.3.20 without issue.
Remember to clear opcache folder
why not like this? php-7.4 is working with nc18.
Ok, I will.
But somehow I think this is the same issue as it started just the same.
Plesk (like OP has) updated my PHP to 7.3.20, and then I couldn’t login anymore.
EDIT: I did. My post is here: https://help.nextcloud.com/t/after-update-to-php-7-3-20-i-cant-login-anymore/87603
PHP 7.3 is the newest version my plesk is offering me.
i tried the following on a ubuntu 16/plesk 18 - for me a rather old system - and i got php 7.4 listed as installable. so i assumed it’s generally available.
plesk installer --select-release-current --show-components
PHP 7.4 is NOT available on Plesk Onyx (v 17).
So all users on Onyx, which is still supported, are out here, or must install a custom PHP handler …
I seem to have found the issue, at least for my case. It seems that the update broke the opcache.
I got a login once, and could navigate to the settings page in which nextcloud told me that opcache wasn’t enabled. However, the plesk settings didn’t change, opcache is enabled (per settings) and I checked the config files.
The module is also installed for the newest php 7.3.
So something seem to be broken with opcache.
After a minute or two my nextcloud went back to 503.
For my part, I only installed updates within Plesk, no PHP upgrade. I am using PHP 7.2 and since the update I can not log in anymore. My installation became unusable.
I saw the same issue on my strato VPS running plesk, with PHP 7.3. and 7.2. ( FPM via Apache)
php is crashing because it calls an illegal (cpu) instruction:
[23-Jul-2020 19:09:45] NOTICE: [pool xxxxxxxxx] child 4318 started
Did some debugging and found that:
Thread 1 "php-fpm" received signal SIGILL, Illegal instruction.
0x00005583a0166e14 in blake2b_init ()
The illegal instruction is:
0x55dc6e6ede14 <blake2b_init+260> vpxor -0x70(%rbp),%ymm0,%ymm0
vpxor is only available if your CPU supports AVX, but it looks like there are some know issues with it e.g.: https://github.com/BLAKE2/libb2/issues/13
blake2 is an hashing algorithm, that is used by the php password hash function if a certain algorithm is selected.
Xdebug gives the line, where nextcloud is using it:
0.6991 2452136 -> password_hash() /xxxxxxxxxxxx/htdocs/nextcloud-u4tjneflsflkjflski/lib/private/Security/Hasher.php:93
The code looks like this:
* Hashes a message using PHP's `password_hash` functionality.
* Please note that the size of the returned string is not guaranteed
* and can be up to 255 characters.
*
* @param string $message Message to generate hash from
* @return string Hash of the message with appended version parameter
*/
public function hash(string $message): string {
$alg = $this->getPrefferedAlgorithm();
if (\defined('PASSWORD_ARGON2I') && $alg === PASSWORD_ARGON2I) {
return 2 . '|' . password_hash($message, PASSWORD_ARGON2I, $this->options);
}
return 1 . '|' . password_hash($message, PASSWORD_BCRYPT, $this->options);
}
I think with Nextcould 18 PASSWORD_ARGON2I is the default.
My workaround to make the login working again was, commenting out the complete if clause that NC is falling back to BCRYPT in any case.
This is a hack to get rid of the symptoms, but doesn’t fix the root cause. Keep following in mind:
- May not work if your logins were not created with BCRYPT in the past
- Will break again if you upgrade Nextcould
- I think there was a good reason to change the hash algo for password hashes
- Root cause is more on the PHP side that was complied with wrong CPU support or the virtualization platform doesn’t support the AVX instruction set.
- need further investigation, please help.
When you have reported, that you don’t have issue, please share
cat /proc/cpuinfo | grep avx
Or have you changed the PW hashing algo or do you use external authentication?
I hope this helps
Bye Thomas
1 Like
To proove, that it is not a nextcould issue, create following a php file with following code:
<html>
<head>
<title>PHP-Test</title>
</head>
<body>
<?php echo '<p>Hallo Welt</p>';
echo password_hash("Test", PASSWORD_ARGON2I )
?>
</body>
</html>
Your should see the same error in the browser and the PHP error log as logging into NC.
Even on the command line, it throws the same exception:
XXX@h2454621:~/XXXXXXXXX/htdocs$ /opt/plesk/php/7.3/bin/php ph_test.php
<html>
<head>
<title>PHP-Test</title>
</head>
<body>
<p>Hallo Welt</p>
Illegal instruction (core dumped)
Now the big question, is it a general php issue, is it an issue how plesk compiles php or is it something related to the virtualization platform.
Ans suggestions for further test are welcome.
1 Like
In that case, if the problem is caused by PHP version from Plesk, you can draw your attention to this KB article, which describes the causes and possible solutions.
The Plesk devs confirmed the bugs and will fix it in the next update.
Also, they give downgrade instructions for those not willing to wait.
IgorG, I didnt realise your KB Article was my bug link. 
I had the same issue after the NC update on PHP 7.3. Could not login.
The solution was to change the Redis / Memcache settings. I changed for Redis to APCu this line:
‘memcache.local’ => ‘\OC\Memcache\APCu’
Then cleared the Redis cache. You have to wait to have this change effective. But it worked som time later.
PHP 7.4 gave also trouble. Not tried this again yet. It could be that these problems are related to IPv6. There is other code generated then with IPv4 connection.
Yesterday, the Plesk team released the update and it fixed the issue.
Login is possible again and everything is running as supposed to
2 Likes