I’m still running Nextcloud 17. According to the system requirements 7.4 is not supported.
@khujo i suggest a solution for your special usecase: upgrade to v18 via console should work on php 7.3, i did myself an upgrade from 18 to 19 “manually” (I stopped using webupdater in general, as it works not that often without flaws).
Then you could switch to php 7.4 maybe, if your server supports that.
I’ll try that. Thank you!
Anyone up with a solution already for nextcloud with php 7.3.20?
I havent had the exact problem. However when I first upgraded to PHP7.4 I had some issues that caused segfaults in php-fpm. It seems that some apps/extensions are a bit buggy and need to be disabled (occ app:disable). For me I’ve had issues with radio, maps, bookmarks and other apps using guzzlehttp library.
1 Like
the problem does not occur because of the PHP version, but only on some servers. e.g. for me with plesk-php-7.2 and 7.3.
Solution: manually install your own PHP (also possible in Plesk) and everything works.
I have this very same problem.
Today the 18.0.7 nextcloud update came out. I installed, and I could log in again. For about 5 minutes, then it went back to “Service unavailable”
@Gjimi How do I install my own PHP in plesk? Any help appreciated!
@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