-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
config.php is reset #12785
Comments
Thanks a lot for reporting issues back to us! We need some more information to properly support you with your issue! Can I ask you to follow our guidelines for submitting bugs as described here: https://github.com/owncloud/core/blob/master/CONTRIBUTING.md Thanks a lot! |
@PVince81 @MorrisJobke looks familiar: {
"app": "PHP",
"message": "require_once(\/var\/www\/owncloud\/3rdparty\/doctrine\/dbal\/lib\/Doctrine\/DBAL\/Driver\/PDOStatement.php): failed to open stream: Too many open files in system at \/var\/www
\/owncloud\/lib\/autoloader.php#142",
"level": 3,
"time": "2014-12-10T21:48:12+00:00"
} |
@jGleitz On which FS type is the ownCloud instance stored? (ext/fat/nfs/etc...) |
Possible related to #10392 in some way. @jGleitz Is XDebug installed on the server? \cc @DeepDiver1975 FYI |
Do you have XDebug + PHP 5.6 ? |
@LukasReschke vzfs . (It's a virtual server) |
@PVince81 PHP 5.5.9 XDebug is not installed (but I can of course install it, if that helps) |
Mhm, my best guesses are that either flock is not working correctly here or that we have some file handle leaks here and that messes up things… … will provide a test script for that later this week or early next week … |
@jGleitz No. It just triggered a problem with the "too many files open". The question just want to drop this possible trouble-maker. ;) |
MorrisJobke - what is about my issue???? |
Reading this from @jGleitz #9736 still seems to be a relevant issue; still without an answer. Open files (Or possibly unclosed files) may be the problem; crashing a possible oc config read which defaults back to known config; which is then written to stateful config? I have never had time to look in to it properly and also never had time to set up parallel envs for all diverse clients/client-versions that may have been propagating the problem. |
I want to inform you that this issue occured again on my installation. (Relevant because it obviously happens under 7.0.4, too.) The behaviour was as described. The Logs were: Apache
Owncloud
|
@jGleitz Set |
Interesting pieces from the log:
|
@LukasReschke, yeah, I'll do that. |
@jGleitz Can you let me know how you setup this server? - Which commands did you execute to install PHP and Apache? - Also did you change some default config options? |
Also when you execute something like |
|
@LukasReschke I rented the server at a hosting Company (1&1). I guess it was set up from a default image for their virtual machines. PHP and Apache was already installed when I moved in. |
Same here, also VM hosted by 1&1. Error occured first in ownCloud 7.0.4 (stable), using webdav. I set the config to read only, Logs repeat these lines:
I cloud try to set up another cloud instance for testing purposes and for further investigation, if you want. update1: update2: update3:
update4:
This script works, but re-writes the config everytime it is read. The server is a VM container, which has limited resources. I read the container's logs today and found some red alerts:
|
I'll get in touch with 1&1 and request a test instance. Hopefully this allows me finally to reproduce this issue reliably. @jGleitz @powerswitch Can you let me know which product you exactly used so I can request it at well? Also how did you install it? Came it installed or had you to request a specific OS? |
Let me setup the test machine later and do some monkey testing (aka clicking around) |
awesome @LukasReschke |
Hello, I've read all this thread due to my config.php getting reset all the time. Nevertheless, I've figure out that the main action I've done to reset my config.php file is an access from thunderbird calendar plugin (lightning ?) My config is different that the ones I've seens here : Basically, the first workaround I've found is to save a working copy of config.php and CRON a copy of the save onto the config.php. |
Please try the changes in #13621 as well |
(and post your system information as well…) |
@manitooo also #12785 (comment) would be nice, since it helps us a lot in finding the right places that cause this. |
@LukasReschke : I am not that fluent with git, so basically, some piece of changes are allright but those from #13621 , I am almost sure that I'll do some mistake. Nevertheless, I've implemented the @nickvergessen comment. Besides, Here are some of my system informations Steps to reproduceno clue, just that it seems to be linked with icedove/iceowl (debian equivalent to thunderbird/lightning) while trying to sync with calendar Expected behaviourIt should get synced (with my old 5.0 OC, it synced this way) Actual behaviourno sync at all, no messages, and config.php erased and replaced by a one byte file Server configurationOperating system: Web server: Database: PHP version: ownCloud version: (see ownCloud admin page) List of activated apps: The content of config/config.php:
Are you using external storage, if yes which one: local/smb/sftp/... Are you using encryption: yes/no Client configurationBrowser: Operating system: LogsWeb server error log
ownCloud log (data/owncloud.log)
Browser logsorry no log |
I actually might have a clue… My assumption is that Lines 142 to 146 in 80560e7
|
The problem also occured/occurs with clients who do not have access to the frontend interface.. native client-app access killed the config. So was/is a problem in the backend due to client-app/version requests.? #9736 Possibly combined with frontend request failure... sometimes the app-clients worked though when touching the frontend the config failed.. so maybe you are all on the right track. |
There might be the case that `fopen($file, 'r')` returns false and thus ownCloud might believe that the config file is empty and thus potentially leading to an overwrite of the config file. This changeset introduces `file_exists` again which was used in ownCloud 5 where no such problems where reported and should not be affected by such problems. Ref #12785 (comment)
@manitooo I have reason to believe that the change ing #13699 should mitigate your problem reported at #12785 (comment) (though there might be other problems in the same file as well) Can you please try that change set as well? Thank you! |
Please notice that the error reported by @manitooo looks different from the one reported by @jGleitz. @manitooo's log:
@jGleitz's log:
|
I have the same problem: Operating system: Web server: Database: PHP version: Owncloud.log |
@gudbergsen You're using Windows which thus is likely to be another problem and your owncloud log shows different information as well. – Can you please test with the above changes applied. Thanks. #13699 should be easy to apply. #13621 requires a little bit more fiddling. The first one might already help. |
@gudbergsen in case you are still facing problem - please open an new issue in there - THX |
OK, just a hint to make it easier to patch the sources. :
Then apply the patch... maybe this could help someone (sorry for kind of out of subject) Regads... I'll do the patch ASAP |
Then, do not try the better try :
then checking what will be done by
the, in case of no errors :
For my case, the patch does not apply nicely :
I'll check later what I have to do |
The patches are intent to be shipped with oc8 - applying them to oc7 will fail - yes |
@LukasReschke I guess we did the best we could have done for OC8 - close? |
jup, i discussed with lukas this morning and we will use a new ticket in case something comes up. |
Steps to reproduce
I don't know :(
Expected behaviour
The config/config.php is never changed unless I explicetly tell ownCloud to do so.
Actual behaviour
From time to time, the config/config.php file is reset to a kind of "default" form (with very few settings, setting a SQLite database as database). This happens about once a week. This causes my cloud to be not reachable for users very often, which is a shame. Plus, I have security concerns about this behaviour.
Server configuration
Operating system:
Ubuntu Server 14.04
File system:
vzfs
Web server:
Apache
Database:
MySQL
PHP version:
5.5.9 - XDebug not (yet) installed
ownCloud version:
7.0.4
Updated from an older ownCloud or fresh install:
updated (from the repository)
List of activated apps:
The content of config/config.php:
Are you using external storage, if yes which one: local/smb/sftp/...
no
Are you using encryption:
no
Client configuration
Unimportant
Logs
Web server error log
ownCloud log (data/owncloud.log)
The access denied message repeats quite often before this
The access denied message repeats quite often in between
The login failes messages repeat very often after this
The .htaccess file is of course not writeable for the apache user, I set my permissions like this (according to the manual):
The text was updated successfully, but these errors were encountered: