The loglevel should stay at 2 so the log does not get filled with info and debug messages.
The loglevel is reset to 0 and the log is getting filled with info and debug messages.
Operating system: Ubuntu Linux 16.04
Web server: Apache 2.4
Database: MariaDB
PHP version: 7.0
Nextcloud version: 13.0.4
Updated from an older Nextcloud/ownCloud or fresh install: Updated
Where did you install Nextcloud from: nextcloud.com
Signing status:
Signing status
No errors have been found.
List of activated apps:
App list
Enabled:
- activity: 2.6.1
- apporder: 0.4.1
- bruteforcesettings: 1.0.3
- calendar: 1.6.1
- caniupdate: 0.1.2
- comments: 1.3.0
- contacts: 2.1.5
- dav: 1.4.7
- deck: 0.3.1
- defaultlinkopen: 1.0.0
- drawio: 0.8.9
- federatedfilesharing: 1.3.1
- federation: 1.3.0
- files: 1.8.0
- files_markdown: 2.0.4
- files_pdfviewer: 1.2.1
- files_sharing: 1.5.0
- files_texteditor: 2.5.1
- files_trashbin: 1.3.0
- files_versions: 1.6.0
- files_videoplayer: 1.2.0
- firstrunwizard: 2.2.1
- gallery: 18.0.0
- logreader: 2.0.0
- lookup_server_connector: 1.1.0
- news: 12.0.4
- nextcloud_announcements: 1.2.0
- notifications: 2.1.2
- oauth2: 1.1.1
- onlyoffice: 1.3.0
- ownpad: 0.6.6
- password_policy: 1.3.0
- provisioning_api: 1.3.0
- serverinfo: 1.3.0
- sharebymail: 1.3.0
- socialsharing_email: 1.0.3
- spreed: 3.2.2
- survey_client: 1.1.0
- systemtags: 1.3.0
- tasks: 0.9.6
- theming: 1.4.5
- theming_customcss: 1.0.0
- twofactor_backupcodes: 1.2.3
- updatenotification: 1.3.0
- workflowengine: 1.3.0
Disabled:
- admin_audit
- encryption
- files_external
- user_external
- user_ldap
Nextcloud configuration:
Config report
{
"system": {
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"nextcloud.0x0c.de"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"skeletondirectory": "",
"overwrite.cli.url": "https:\/\/nextcloud.0x0c.de",
"dbtype": "mysql",
"version": "13.0.4.0",
"installed": true,
"htaccess.RewriteBase": "\/",
"maintenance": false,
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"memcache.local": "\\OC\\Memcache\\APCu",
"knowledgebaseenabled": false,
"theme": "",
"loglevel": 0,
"mysql.utf8mb4": true,
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_smtpmode": "php",
"mail_smtpauthtype": "LOGIN",
"mail_domain": "***REMOVED SENSITIVE VALUE***"
}
}
Are you using external storage, if yes which one: no
Are you using encryption: no
Are you using an external user-backend, if yes which one: no
Browser: Firefox 60.0
Operating system: Windows 10 Pro
@arnowelzel Could you check if there are more files in config/ and what their content is? (maybe strip away sensitive values)
The config report says that the log level is indeed 0.
GitMate.io thinks possibly related issues are https://github.com/nextcloud/server/issues/1265 (Always show console.log), https://github.com/nextcloud/server/issues/6593 (Upgrade from NC 12.0.2 to NC 12.0.3, the loglevel isn't reset after upgrade), https://github.com/nextcloud/server/issues/6012 (Internal Server error after 12.0.1 upgrade), https://github.com/nextcloud/server/issues/9179 (Slow log out.), and https://github.com/nextcloud/server/issues/9922 (server replied: Locked).
@MorrisJobke config.sample.php (came with Nextcloud) and mimetypemapping.json which I created to add additional MIME types according to https://docs.nextcloud.com/server/13/admin_manual/configuration_mimetypes/index.html.
If it helps: I believe the issue started after updating to NC 13.0.4. Before I never had this problem.
I just have reset the loglevel back to 2 and will monitor this.
Just a quick update: about 22 hours have passed and so far the loglevel didn't change :-). If it happens again, I'll let you know. If it stays like that for another 24 hours I will close this issue.
Another 17 hours passed without any problem - which is good :-). I'll close this issue now. On the other hand: I really had this strange effect in the last 10 days multiple times. Can a Nextcloud plugin change the debug level on its own?
Now it happend again. At 2016-06-22 11:58 UTC, the loglevel was reset to 0 again :-(.
At that time I was using the "Deck" app in the browser.
So the question is: under which circumstances may the loglevel be changed?
Very strange, indeed: I did reset the loglevel to 2. It got immediatly reset to 0 when I was using the Gallery app and the following error was logged:
Debug | core | OC_Image->loadFromBase64, could not load
Then I manually reset the loglevel back to 2 again, entered the Gallery again - and nothing happens. The loglevel stays at 2. Also entering "Deck" again etc. does not change anything.
So the really interesting question here is: why does Nextcloud change the loglevel at all? Somewhere in the code of Nextcloud or in of the apps there must be some code doing this. So far I know about the updater. But there may be other components as well doing this? I'll try to find the possible calls for this in the code tonight and maybe also the cause for that.
I think, I found it: https://github.com/nextcloud/logreader/issues/68
This is true here as well - because when using the logreader I have "debug" usally filtered out. To check, if the loglevel was reset back to 0 again, I activated the "debug" checkbox in the logreader filter and this causes the loglevel to be reset to 0.
I think the problem is this here (apps/logreader/lib/Controller/LogController.php, line 185-197):
public function setLevels($levels) {
$intLevels = array_map('intval', str_split($levels));
$minLevel = 4;
foreach ($intLevels as $level => $log) {
if ($log) {
$minLevel = $level;
break;
}
}
$this->config->setSystemValue('loglevel', $minLevel);
$this->config->setAppValue('logreader', 'levels', $levels);
return $minLevel;
}
Why does the system wide loglevel of Nextcloud get changed, just because the filter in the logreader view is changed? When I turn on debug messages in the filter of the logreader view this does not mean, I want to change the system wide loglevel to "debug". A reader should never change anything in the system, never.
I would just delete $this->config->setSystemValue('loglevel', $minLevel);.
Since this bug is a flaw in the logreader app and not the server itself, I close this issue.
That log reader filter is also the setting in the UI. But I would be fine to keep it a filter only and allow only changing the log level in the config.php. Could you mention me in that ticket?