<p dir="auto"><strong>Elasticsearch version</strong>: 2.3.5</p>
<p dir="auto"><strong>JVM version</strong>: OpenJDK Runtime Environment (IcedTea 2.6.7) (7u111-2.6.7-1~deb8u1)</p>
<p dir="auto"><strong>OS version</strong>: Debian 8.5</p>
<p dir="auto"><strong>Description of the problem including expected versus actual behavior</strong>: log messages are written to <code class="notranslate">${path.logs}/${cluster.name}.log</code> <strong>and</strong> <code class="notranslate">stdout</code>. When using SystemD, logs end up in two files (ES log and syslog)</p>
<p dir="auto">I don't see a good reason to keep both locations for logs (see "the bad" section here : <a href="http://www.kibinlabs.com/systemd-logging-tricks/" rel="nofollow">http://www.kibinlabs.com/systemd-logging-tricks/</a>)</p>
<p dir="auto">When we moved query parsing on the coordinating node (see <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="63624736" data-permission-text="Title is private" data-url="https://github.com/elastic/elasticsearch/issues/10217" data-hovercard-type="issue" data-hovercard-url="/elastic/elasticsearch/issues/10217/hovercard" href="https://github.com/elastic/elasticsearch/issues/10217">#10217</a>), we added a new <code class="notranslate">SearchSourceBuilder#fromXContent</code> method that given an <code class="notranslate">XContentParser</code> and the current <code class="notranslate">QueryParseContext</code> parses and creates a new <code class="notranslate">SearchSourceBuilder</code> object. The parse code ends up duplicating what we already have in our <code class="notranslate">SearchParseElement</code> classes. We made a choice not to refactor these initially as they depend on <code class="notranslate">SearchContext</code> and there are still apis that use them to parse lucene queries straight-away and set them to the search context rather than going through our intermediate query representation.</p>
<p dir="auto">This solution can only be temporary though, as we are currently duplicating parsing code. What we should do ideally instead, is move over parsing code to the new solution (either <code class="notranslate">SearchSourceBuilder#fromXContent</code> or an updated version of <code class="notranslate">SearchParseElement</code> that doesn't depend on <code class="notranslate">SearchContext</code>) and get rid of the previous parsing code. I realize how this becomes hard to do given that we have not moved yet all of the search sections over. Maybe we should wait till the search refactoring is completed, but after that  we should clean this up and have only one way to parse search sections, with code in one single place, otherwise it becomes hard to understand how each api parses search sections.</p>