Open joekerna opened 3 years ago
cc @nickvergessen
user@server:\~$ occ update:check
Everything up to date user@server:~$ occ app:update --all
calendar new version available: 2.2.0
calendar updated
Only difference I can see is:
update:check
loops over:
https://github.com/nextcloud/server/blob/d7c0b9cced2dff16e4e05507ac58cf8664a6aafc/apps/updatenotification/lib/Command/Check.php#L78
While app:update --all
loops over:
https://github.com/nextcloud/server/blob/2a054e6c04e0a40421510eb889cbf59f153c5177/core/Command/App/Update.php#L102
But there shouldn't be a difference unless you have apps in your server which you didn't install at all
I don't understand. Some apps were there from the beginning (like calendar) and some I've installed manually (like facerecognition). But somehow they we all installed, right?!
Yeah this was more technical information for other developers if someone has time to look at it.
I just debugged it on my server and for me the assumption is correct. I had 2 apps not showing up in update:check (contacts and richdocuments) but both are disabled:
$ sudo -u www-data /var/www/nextcloud/occ config:list richdocuments
{
"apps": {
"richdocuments": {
"disable_certificate_verification": "yes",
"enabled": "no",
"installed_version": "3.7.17",
"types": "filesystem,dav,prevent_group_restriction",
"wopi_url": "…"
}
}
}
$ sudo -u www-data /var/www/nextcloud/occ config:list contacts
{
"apps": {
"contacts": {
"enabled": "no",
"installed_version": "3.5.1",
"types": "dav"
}
}
}
$ sudo -u www-data /var/www/nextcloud/occ app:list
Enabled:
- accessibility: 1.6.0
- activity: 2.13.4
- analytics: 3.4.1
- calendar: 2.2.0
- cloud_federation_api: 1.3.0
- comments: 1.10.0
- contactsinteraction: 1.1.0
- cospend: 1.3.0
- dashboard: 7.0.0
- dav: 1.16.2
- deck: 1.2.5
- dropit: 0.4.0
- event_update_notification: 1.2.0
- federatedfilesharing: 1.10.2
- federation: 1.10.1
- files: 1.15.0
- files_accesscontrol: 1.10.2
- files_automatedtagging: 1.10.1
- files_markdown: 2.3.3
- files_pdfviewer: 2.0.1
- files_rightclick: 0.17.0
- files_sharing: 1.12.2
- files_trashbin: 1.10.1
- files_versions: 1.13.0
- files_videoplayer: 1.9.0
- firstrunwizard: 2.9.0
- logreader: 2.5.0
- lookup_server_connector: 1.8.0
- mail: 1.9.3
- nextcloud_announcements: 1.9.0
- notifications: 2.8.0
- oauth2: 1.8.0
- password_policy: 1.10.1
- photos: 1.2.3
- privacy: 1.4.0
- provisioning_api: 1.10.0
- recommendations: 0.8.0
- richdocumentscode: 6.4.705
- settings: 1.2.0
- sharebymail: 1.10.0
- spreed: 10.0.6
- support: 1.3.0
- survey_client: 1.8.0
- suspicious_login: 3.2.1
- systemtags: 1.10.0
- tasks: 0.13.6
- text: 3.1.0
- theming: 1.11.0
- twofactor_backupcodes: 1.9.0
- updatenotification: 1.10.0
- user_status: 1.0.1
- viewer: 1.4.0
- weather_status: 1.0.0
- workflowengine: 2.2.0
Disabled:
- contacts
- richdocuments
So yeah, it's a bit weird that app:update --all updates apps which are not enabled, but then again it could be the itention, because you can't enable the app right now unless you update it e.g. due to major upgrade with incompatibility.
But from my POV IAppManager::getInstalledAppsValues
should return a list of installed apps, not a list of enabled apps? Confusing part is then:
https://github.com/nextcloud/server/blob/d89a75be0b01f0423a7c1ad2d58aac73c3cc1f3a/lib/private/App/AppManager.php#L143-L145
Although we might need both methods getInstalledApps
and getEnabledApps
Hi, please update to 24.0.9 or better 25.0.3 and report back if it fixes the issue. Thank you!
My goal is to add a label like e.g. 25-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!
If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+
@szaimen I had my scripts such that they do a app:update --all first, and then a update:check. I now swapped these and added some text delimiter so that I will see if the OP bug description happens again. And it did, on a 25.0.3 instance (release channel):
--- Executing update:check ---
Everything up to date
--- Executing app:update --all ---
calendar_resource_management new version available: 0.4.0
calendar_resource_management updated
Same today, on an NC 26.0.0beta1 instance (beta channel):
--- Executing update:check ---
Update for snappymail to version 2.25.2 is available.
1 update available
--- Executing app:update --all ---
contacts new version available: 5.1.0
contacts updated
snappymail new version available: 2.25.2
snappymail updated
Seems like the issue still exists.
I just got the below output from the script that iterates through my instances and does
occ update:check
occ app:update --all
for each of them. The whole script runs approximately 10 seconds. Output abbreviated to such instances that show different outputs.
--- 1 latest beta, bare minimum apps plus twofactor apps ---
update:check
Everything up to date
app:update --all
twofactor_nextcloud_notification new version available: 3.6.0
twofactor_nextcloud_notification updated
--- 2 latest beta, production instance (new 26.0.0beta1install upgraded to beta2,3,4)
update:check
Update for twofactor_nextcloud_notification to version 3.6.0 is available.
1 update available
app:update --all
--- 3 latest stable, stage instance
update:check
Update for twofactor_nextcloud_notification to version 3.6.0 is available.
1 update available
app:update --all
twofactor_nextcloud_notification new version available: 3.6.0
twofactor_nextcloud_notification updated
--- 4 latest stable, production instance
update:check
Everything up to date
app:update --all
Whereas latest beta
here refers to NC26.0.0.6 (beta4) and latest stable
to NC25.0.3.2.
In 1
, update:check claims "all apps are updated" whereas app:update finds and installs the update.
In 2
, it' vice versa. Although update:check yields an update, app:update does not find it and thus doesn't install it.
In 3
, both commands see the update and it is installed.
In 4
, both commands don't see the update and thus do nothing.
So, what's the deal here? Running that script regularly interactively, I quite often experience that a certain app is seen and updated by some instances, and e.g. an hour later by others, and even another hour later by the rest of the instances. So both commands seem to have some local caching or a throttle that prevents them from actually asking the server. I think the issue is about that these mechanisms are not in sync for one instance in itself (and among multiple instances on one server).
OR … ( I may have spoken too soon) … it's just an access issue on the apps.nextcloud.com loadbalancer or sorts:
{"reqId":"BBvGCeJOW9OcsKtm0R2x","level":2,"time":"2023-02-21T22:16:48+01:00","remoteAddr":"","user":"--","app":"appstoreFetcher","method":"","url":"--","message":"Could not connect to appstore: cURL error 7: Failed to connect to apps.nextcloud.com port 443 after 23 ms: Couldn't connect to server (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://apps.nextcloud.com/api/v1/apps.json","userAgent":"--","version":"26.0.0.6","data":{"app":"appstoreFetcher"}}
Learning about the occ update:check
command, I realized there is the same issue with our instance.
As occ app:update --all
runs the updates and changes the state of things, it's easier to debug with occ app:update --showonly
to prevent the updates from actually running, but only show them.
I agree with some comments, that an ideal solution would provide some more context or options to either distinguish between active and disabled as well as compatible and incompatible apps or include/exclude them with an additional flag. However, I think it would be best to rectify the outlined issue first and then approach additional features. Without code comments, it's hard to understand which behaviour is intentional and which is not. One of those feature requests already exists as #32691
A lot of times
occ update:check
returnsand when I still run
occ app:update --all
afterwards I get do get updates.The entire shell looks like this:
or later the same day: