Open geraldurbas opened 1 year ago
I believe this white-screen happens when a new entry is added to the log. If this helps debugging.
I believe this white-screen happens when a new entry is added to the log. If this helps debugging.
Correct - the white screen happens when a new error is generated.
@solracsf marked https://github.com/nextcloud/server/issues/35659 as a duplicate (correctly -- apologies: I do not know why my searches did not throw up this one). I am on later versions of most apps, OS, kernel, etc. so it may be worth refering back to this.
Note for me the logging page goes blank immediately, I just get a flash of what I expect to see. This is different from what @geraldurbas reports.
@kesselb asked for more info https://github.com/nextcloud/server/issues/35659#issuecomment-1341681241
After a page refresh a copy/paste from the console is:
10:57:27.008 JQMIGRATE: Migrate is installed, version 3.4.0 jquery-migrate.min.js:2:698
10:57:27.412 [DEBUG] unified-search: Unified Search initialized with the following providers
Object { 0: {?}, 1: {?}, 2: {?}, 3: {?}, 4: {?}, 5: {?}, 6: {?}, 7: {?}, level: 0, app: "unified-search", ? }
?
0: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
??
__ob__: Object { shallow: false, mock: false, vmCount: 0, ? }
??
id:
??
name:
??
order:
??
<get id()>: function get()??
<set id()>: function set(t)??
<get name()>: function get()??
<set name()>: function set(t)??
<get order()>: function get()??
<set order()>: function set(t)??
<prototype>: Object { ? }
?
1: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
2: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
3: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
4: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
5: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
6: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
7: Object { id: Getter & Setter, name: Getter & Setter, order: Getter & Setter, ? }
?
app: "unified-search"
?
level: 0
?
uid: "admin"
?
<prototype>: Object { ? }
??
__defineGetter__: function __defineGetter__()
??
__defineSetter__: function __defineSetter__()
??
__lookupGetter__: function __lookupGetter__()
??
__lookupSetter__: function __lookupSetter__()
??
__proto__:
??
constructor: function Object()
??
hasOwnProperty: function hasOwnProperty()
??
isPrototypeOf: function isPrototypeOf()
??
propertyIsEnumerable: function propertyIsEnumerable()
??
toLocaleString: function toLocaleString()
??
toString: function toString()
??
valueOf: function valueOf()
??
<get __proto__()>: function __proto__()
??
<set __proto__()>: function __proto__()
ConsoleLogger.js:52:10
10:57:27.573 Got notification data NotificationsApp.vue:384
10:57:27.573 Polling interval updated to 30000 NotificationsApp.vue:421
10:57:57.546 No new notification data received NotificationsApp.vue:389
10:57:57.547 Polling interval updated to 30000 NotificationsApp.vue:421
10:58:27.560 No new notification data received NotificationsApp.vue:389
10:58:27.560 Polling interval updated to 30000 NotificationsApp.vue:421
10:58:57.564 No new notification data received NotificationsApp.vue:389
10:58:57.564 Polling interval updated to 30000 NotificationsApp.vue:421
10:59:27.553 No new notification data received NotificationsApp.vue:389
10:59:27.554 Polling interval updated to 30000 NotificationsApp.vue:421
10:59:57.571 No new notification data received NotificationsApp.vue:389
which to me looks pretty blank (as in lots of calls with default/blank parameters).
How can I help drill this down to more useful information?
I am running Nextcloud 25.0.2 on several servers and one of them is facing the same issue. I don't have LDAP authentication active on that server (answering to this comment) so it seems to be unrelated to that specific plugin.
Same problem here. Nextcloud 25.0.3.
The debug file exists, and it has the right permissions. It is correctly configured in the config
file.
It remains empty, and the logging interface is empty as well.
When I run php occ log:manage
it returns this:
{"reqId":"wsrPsOz03jSNXMvU9Nq5","level":1,"time":"2023-01-19T13:34:12+00:00","remoteAddr":"","user":"--","app":"related_resources","method":"","url":"--","message":"Could not resolve OCA\\Circles\\CirclesManager! Class \"OCA\\Circles\\CirclesManager\" does not exist","userAgent":"--","version":"25.0.3.2","data":{"app":"related_resources"}}
{"reqId":"wsrPsOz03jSNXMvU9Nq5","level":1,"time":"2023-01-19T13:34:12+00:00","remoteAddr":"","user":"--","app":"admin_audit","method":"","url":"--","message":"Console command executed: log:manage","userAgent":"--","version":"25.0.3.2","data":{"app":"admin_audit"}}
Enabled logging backend: file
Log level: Info (1)
Log timezone: UTC
Changing the Log Level in the config
file is reflected accordingly in the message. I don't know why the Circles app is referred to. It is disabled. If I enable it, the first part disappears. If I disable the Audting/Logging app, the second part disappears. Either way the log file stays empty, so I don't think this is related.
Also, changing the debug level within the web interface is not reflected in the config
file. Weird.
Any improvement if you change the log level from Info (1) to Warn (2)? You can chance this by editing config/config.php in the nextcloud folder.
Checked again on 25.0.2, no blank-white display for me any longer (I don't know what happened to resolve the issue). Upgraded to 25.0.3, no issue for me.
I am experiencing this issue on Nextcloud server 28.0.0 RC2, the logging page only open a blank page
I also have the blank screen in the logging section with 28.0.0
The console of Chrome shows the following error:
Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "application/octet-stream". Strict MIME type checking is enforced for module scripts per HTML spec.
I'm having the same issue as described by @Fred-Zweig, since I upgraded from Nextcloud 27.n.5 to 28.0.1:
Interestingly, the same issue occurs with the Activity app - see https://github.com/nextcloud/activity/issues/1196
I'm running nginx 1.25.1 and PHP 8.1.2.
@Fred-Zweig @loddi @benklaasen Please refer to the NC27 Admin Manual release notes and/or other closed issues in this repo. Your configuration is not up-to-date for handling of .mjs
files. This is not a bug, but a local config matter with your web server. In addition, it's unrelated to the Issue you're commenting on (this one), as the log reader in NC25 versus NC28 was a complete rewrite on the front end.
Follow-up on the Nextcloud Help Forum if needed - https://help.nextcloud.com
I have the same problem. Just saying:
Nextcloud Hub 7 (28.0.1)
$ php --version
PHP 8.1.2-1ubuntu2.14 (cli) (built: Aug 18 2023 11:41:11) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.2, Copyright (c) Zend Technologies
with Zend OPcache v8.1.2-1ubuntu2.14, Copyright (c), by Zend Technologies
with Xdebug v3.1.2, Copyright (c) 2002-2021, by Derick Rethans
I can see the log file in the data director as nextcloud.log. It looks recently updated and is about 10MB in size.
I don't see any console errors in the browser though.
@bernd-wechner Your situation is likely entirely unrelated to the reported issue here. NC28's logreader has a completely rewritten front-end. Chances are you're encountering one of the configuration/local environment matters that have hit NC28 users:
@joshtrichards I knew that my issue was not identical with the one described in the opening post, yet it was similar and I didn't want to open a separate issue. Anyway, I can confirm now that adding
include /etc/nginx/mime.types;
types { text/javascript js mjs; }
to my Nginx configuration as shown here, solved the problem: now the Logging page loads correctly and so does the Activity page. Yet, I don't consider this as a proper solution. The best solution would have been to implement all the functionalities added via the .mjs
files using simple .js
files. We shouldn't let ourselves be forced by Node.js developers (paid by Google) to adopt new file extensions.
@bernd-wechner Your situation is likely entirely unrelated to the reported issue here. NC28's logreader has a completely rewritten front-end. Chances are you're encountering one of the configuration/local environment matters that have hit NC28 users:
* ad blocker browser extension (many have had false positives blocking NC28's new logreader) * mjs file handling missing from web server config (see the NC27 upgrade docs where this was functionality was first required though logreader didn't require it until NC28)
Spot on. I added ".mjs" to my mimetypes configuration as "application/javascript" and the Forms app came good! Turns out .mjs
is an ES6 extensions and seemingly hasn't made it into all default mime type declarations and configs yet. But logging has returned! (as has Forms, it too was impacted)
Yet, I don't consider this as a proper solution
But is a proper solution. Welcome to the web. Things inch forwards. ES6 introduced a new module packaging extensions and not all webservers have absorbed it in their mime default configurations yet. PITA, yes. Proper solution, most definitely. Better transition desirable - probably (as in the Administration Overview Tests that run could check for .mjs support and report if missing, given this is a likely issue folk encounter in upgrading).
Better transition desirable - probably (as in the Administration Overview Tests that run could check for .mjs support and report if missing, given this is a likely issue folk encounter in upgrading).
nextcloud/server#42436 :-)
Better late than never! Just three days old. Backported too so it'll be in upcoming v28.0.2.
Things inch forwards. ES6 introduced a new module packaging extensions and not all webservers have absorbed it in their mime default configurations yet.
Things are believed to inch forwards. It doesn't mean they do. Have you read this thread, or asked yourself why Nginx developers were still reluctant to add the new .mjs
file extension to the list of default MIME types supported by Nginx ? Even today, the latest version of Nginx doesn't officially support .mjs
files. All the functionalities added via .mjs
files could have been added using simple .js
files if someone took the time to do it. If tomorrow, some Node.js deveopers paid by Google decide to invent a new extension, let's say .djs
, would you eagerly change your Nginx configuration to adopt the new file extension just because it was imposed by Google ? I wouldn't. Maybe you should first investigate who is paying and controlling the developers who promote the sub-optimal runtime environment called Node.js, before going with the flow.
Things inch forwards. ES6 introduced a new module packaging extensions and not all webservers have absorbed it in their mime default configurations yet.
Things are believed to inch forwards. It doesn't mean they do. Have you read this thread, or asked yourself why Nginx developers were still reluctant to add the new
.mjs
file extension to the list of default MIME types supported by Nginx ? Even today, the latest version of Nginx doesn't officially support.mjs
files. All the functionalities added via.mjs
files could have been added using simple.js
files if someone took the time to do it. If tomorrow, some Node.js deveopers paid by Google decide to invent a new extension, let's say.djs
, would you eagerly change your Nginx configuration to adopt the new file extension just because it was imposed by Google ? I wouldn't. Maybe you should first investigate who is paying and controlling the developers who promote the sub-optimal runtime environment called Node.js, before going with the flow.
Well, I added it as 'application/javascript' and all is fine. I don't use nginx, but lighttpd (as I don't need a sluggish dinosaur like Apache, and prefer freeware that favoured by my gateway than freemium software where possible and lighttpd performs on par with nginx in scaleability and resource efficiency).
But as @joshtrichards points out, Nextcloud is adding a check to the Overview page (and I concur, better late than never).
I'm not here to judge what Noe.JS do or nginx do or Nextcloud for that matter, and suggest humbly that judgement as a rule isn't constructive to any part of the FOSS world, and best replaced by humble suggestions. Fret not, we all venture into judgement on our darkest, most frustrated days ;-).
Given it was easy to fix all is good and I'm pleased the nextcloud will check and report in future (that is something of import as I don't mind fixing problems if they are easily diagnosed and fixed, but mysterious failures with no easy clues are time-consuming bothers I grant.
⚠️ This issue respects the following points: ⚠️
Bug description
Opening the Logging Screen shows errors. After a few seconds only a white blank is displayed. JS Error thrown:
Steps to reproduce
Expected behavior
Log entries keep visible
Installation method
Other Community project
Operating system
Debian/Ubuntu
PHP engine version
PHP 7.4
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
No response
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
No response
Additional info
No response