Zeroing, resetting, rebuilding ... the app pkg mgmt accounting

Short into: upgraded from php 7.3 to 8.0. Everything works, but installing or upgrading any app is broken. As in repeatedly reproducibly broken.

My Question:

Can I (any one of) reset, zero, rebuild the package (app) database or accounting? I don’t see it in the list of things that occ can do. I’m comfortable with the PostgreSQL terminal. I just need a nudge here so I don’t have to read reams of source to figure a path through.

What I’m saying is: the nextcloud logs and the behaviour of the nextcloud update app process lead me to believe that somewhere in the php upgrade process (which was, TBH, strange) the accounting for apps and their installations was fubar’d.

I’d like to not loose application information. Right now, all the apps (save the one I disabled for a test) are working just fine… it’s simply the upgrade or install that is broken.

OK. Can I make my ask simpler? I don’t think so. If this is a “go read the code” … can I at least get pointers to what modules manage plugin apps?

Check you logfiles first. Often, people forget to install al required php modules (https://docs.nextcloud.com/server/stable/admin_manual/installation/source_installation.html).

Yes. I also think you now perhaps missed some php software like php-curl for downloading apps.

Example (please do not use cut-and-paste):

apt install -y php php-curl php-cli php-mysql php-gd php-common php-xml php-json php-intl php-pear php-imagick php-dev php-common php-mbstring php-zip php-soap php-bz2 php-bcmath php-gmp php-apcu

https://www.howtoforge.com/how-to-install-nextcloud-on-debian-11

If it not works please post some logs.

Also you can post (Ubuntu and Debian):

dpkg -l |grep php

thank-you for your reply. FreeBSD pkg mgmt, so I can’t cut’n’paste, but I have php-curl:

[2:2:302]root@nextcloud:/> pkg info | grep curl
curl-7.81.0                    Command line tool and library for transferring data with URLs
php80-curl-8.0.17              The curl shared extension for php

I posted above what the nextcloud log says when I cause this issue. It’s the only log that says anything at all. nginx log is just a regular bunch of 200-status requests. fpm’s log actually doesn’t say anything (I assume because nothing spits out stdout junk). The nextcloud log is set at ‘0’ … which according to the docs is “maximum” …

It’s FreeBSD … so this is my equivalent of your request (below). I would really like to know where the package management for nextcloud is stored to I can reverse engineer it. Or maybe one of you knows how to coax more verbose logging of the problem out of nextcloud. As above, the logs aren’t very talkative and wherever this error happens … doesn’t itself kick out a log line — it just leaves the system in maintenance state.

[2:1:301]root@nextcloud:/> pkg info | grep php
nextcloud-php80-23.0.3         Personal cloud which runs on your own server
php80-8.0.17                   PHP Scripting Language
php80-bcmath-8.0.17            The bcmath shared extension for php
php80-bz2-8.0.17               The bz2 shared extension for php
php80-ctype-8.0.17             The ctype shared extension for php
php80-curl-8.0.17              The curl shared extension for php
php80-dom-8.0.17               The dom shared extension for php
php80-exif-8.0.17              The exif shared extension for php
php80-fileinfo-8.0.17          The fileinfo shared extension for php
php80-filter-8.0.17            The filter shared extension for php
php80-ftp-8.0.17               The ftp shared extension for php
php80-gd-8.0.17                The gd shared extension for php
php80-gmp-8.0.17               The gmp shared extension for php
php80-iconv-8.0.17             The iconv shared extension for php
php80-imap-8.0.17              The imap shared extension for php
php80-intl-8.0.17              The intl shared extension for php
php80-ldap-8.0.17              The ldap shared extension for php
php80-mbstring-8.0.17          The mbstring shared extension for php
php80-opcache-8.0.17           The opcache shared extension for php
php80-pcntl-8.0.17             The pcntl shared extension for php
php80-pdo-8.0.17               The pdo shared extension for php
php80-pdo_mysql-8.0.17         The pdo_mysql shared extension for php
php80-pdo_pgsql-8.0.17         The pdo_pgsql shared extension for php
php80-pecl-APCu-5.1.21         APC User Caching
php80-pecl-imagick-3.5.1       PHP wrapper to the ImageMagick/GraphicsMagick library version 6
php80-pgsql-8.0.17             The pgsql shared extension for php
php80-phar-8.0.17              The phar shared extension for php
php80-posix-8.0.17             The posix shared extension for php
php80-session-8.0.17           The session shared extension for php
php80-simplexml-8.0.17         The simplexml shared extension for php
php80-xml-8.0.17               The xml shared extension for php
php80-xmlreader-8.0.17         The xmlreader shared extension for php
php80-xmlwriter-8.0.17         The xmlwriter shared extension for php
php80-xsl-8.0.17               The xsl shared extension for php
php80-zip-8.0.17               The zip shared extension for php
php80-zlib-8.0.17              The zlib shared extension for php

Just looking up there — the only inaccurate thing may be the “nextcloud-php80-23.0.3” … because this is obviously a situation where nextcloud updated itself … so FreeBSD’s package management doesn’t know that.

And now you have installed the required packages manually?

For the logs and log level of Nextcloud:
https://docs.nextcloud.com/server/stable/admin_manual/issues/general_troubleshooting.html

For php-fpm you can increase the loglevel in the corresponding php configuration files.

On the command line, you have php8 as well (check with php -v), you can try to disable the maintenance mode: su -m www -c "php occ maintenance:mode --off"

Well… all the packages were already loaded. The log level is already ‘0’ (which is claimed to be Debug or ‘All’. I added ‘debug’ => true, to the config.php array.

… then I entered debug and tried to update ‘Forms’ again:

image

That error: is very wide. Here’s the text:

error: TypeError: Cannot read properties of undefined (reading 'message') at c.APPS_API_FAILURE (https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:47336) at https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:32:140745 at https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:637 at Array.forEach (<anonymous>) at https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:616 at c._withCommit (https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:2446) at c.commit (https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:590) at Object.commit (https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:32:138210) at https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:52239
message: "Cannot read properties of undefined (reading 'message')"
stack: "TypeError: Cannot read properties of undefined (reading 'message')\n    at c.APPS_API_FAILURE (https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:47336)\n    at https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:32:140745\n    at https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:637\n    at Array.forEach (<anonymous>)\n    at https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:616\n    at c._withCommit (https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:2446)\n    at c.commit (https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:590)\n    at Object.commit (https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:32:138210)\n    at https://nextcloud.towernet.ca/apps/settings/js/vue-settings-apps-users-management.js:38:52239"

You have the dependencies for the packages via ports at the lower part of this page:
https://www.freshports.org/www/nextcloud

Not sure about your error, can you easily go into the code at which part it fails. Perhaps it is linked to some content that couldn’t be loaded?

If you could run the occ command further up, you can try and update the apps through the same command: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/occ_command.html#apps-commands-label
There is no javascript and you get a better error message (or even no error).

This does indeed get interesting.

[nextcloud@nextcloud ~/nextcloud]$ php occ app:update forms
forms new version available: 2.5.0
Illegal instruction (core dumped)

!?!

(gdb) bt
#0  0x0000000802ecf5ae in __gmpz_set_str () from /usr/local/lib/libgmp.so.10
#1  0x0000000802e8a149 in zif_gmp_init () from /usr/local/lib/php/20200930/gmp.so
#2  0x0000000802e8a024 in zif_gmp_init () from /usr/local/lib/php/20200930/gmp.so

Mostly just posting this for other people … I can probably track this down (will report back) … apparently libgmp … I’m assuming is compiled for “not this processor”

There-you-go. So… I can guarantee you that the manual upgrade invocation (which I didn’t know about — and I don’t think it was listed in occ help … which I did peruse) spit out text that I didn’t see in any other logfile. Really… it would be handy to bubble text like that up to the user.

Can you check the app and core signatures as well? Sometimes people end up with code mixed from different versions (https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/occ_command.html#integrity-check-label).
It comes handy for a bug report as well :wink:

[nextcloud@nextcloud ~/nextcloud]$ php occ integrity:check-core | grep 3rdparty | cut -d/ -f1-2 | uniq -c
 746     - 3rdparty/aws
1305     - 3rdparty/giggsey
   1     - 3rdparty/symfony

… not good, I imagine. Since the page you reference says that check-core is for developers — I assume what I do next should be on your advice, too…