<p dir="auto">There are some cases where dpkg/apt can leave file like logging.yml.dpkg-dist files in /etc/elasticsearch and LogConfigurator will pick them up by default.  This is bad because those files might contain garbage and break logging.  Why not <em>just</em> pick up logging.yml?  Is this something like the <a href="http://serverfault.com/a/240182/151116" rel="nofollow">conf.d</a> pattern?</p>
<p dir="auto">elasticsearch 1.3 will try to import .svn/text-base/logging.yml.text-base as json and fail to set up logging as a whole.<br>
I think it's not reproducible with subversion 1.7+ since a new .svn-format with hash-based filenames is used. But Debian wheezy/stable is still using subversion 1.6 and is what we use.<br>
I found <a href="https://github.com/elasticsearch/elasticsearch/blob/1.3/src/main/java/org/elasticsearch/common/logging/log4j/LogConfigurator.java#L107">https://github.com/elasticsearch/elasticsearch/blob/1.3/src/main/java/org/elasticsearch/common/logging/log4j/LogConfigurator.java#L107</a> which is the problematic part.<br>
imo it should at least skip "hidden" directories, if not be limited to some more strict rules (file extension whitelist without the "catch-all" default, ...).</p>
<p dir="auto">I thought of only ignoring the failed file, but that could lead to strange errors too.<br>
What if you have a logging.json. Then you would have a .svn/text-base/logging.json.text-base, which could import and override the original logging.json (local modified logging.json). =&gt; quite troublesome to find out why the changes don't work until you commit them :)</p>
<h5 dir="auto">Known workarounds (also see <a href="https://groups.google.com/forum/#!topic/elasticsearch/8zlwEj12DjI" rel="nofollow">https://groups.google.com/forum/#!topic/elasticsearch/8zlwEj12DjI</a>):</h5>
<ol dir="auto">
<li>Add "copy/move to logging.yml" command before startup (so that the file in .svn doesn't start with "logging.")</li>
<li>mount an empty directory over .svn (tmpfs, ...). Umount/mount if needed to work with svn &lt;= that's the solution we use, since we mount it readonly over nfs and cp/mv doesn't work</li>
</ol>
<p dir="auto">I think both workarounds are quite dirty hacks and you shouldn't be forced to use those, just because you use a vcs.</p>