systemd causes always logging to stdout

[111andre111]

By default, the apm-server systemd file in 7.0.0 as well as 7.0.1 is adding the -e option. This causes that configuration in apm-server.yml around
logging.to_files: true
is not possible at the moment, because no log files will be written.
I have tested under both, Redhat and Ubuntu.

I've temporarily changed the value in the systemd file
/etc/systemd/system/multi-user.target.wants/apm-server.service
from

Environment="BEAT_LOG_OPTS=-e"

to

Environment="BEAT_LOG_OPTS="

This didn't break in the tests any functionality.
Without configuration of logging.to_files it just landed in

journalctl -f -u apm-server

and with configuration of logging.to_files: true the logfile was normally written under
/var/log/apm-server
or wherever you configure the destination path.

I found that there was a decision for adding the -e parameter here:
elastic/beats#8942
https://github.com/elastic/apm-server/blob/master/changelogs/7.0.asciidoc#apm-server-version-700-alpha2
but it should be taken into consideration that it did break the to_files possibility.

[simitt]

Thank you for the report! Have you seen the documentation for logging with systemd?

It has a detailed explanation on how to customize logging with systemd, by using the BEAT_LOG_OPTS parameter.
It looks like that's exactly what you used to change the default behaviour. You also mention you didn't run into any issues with that change. Therefore, unless there is anything else that I am missing, I suggest to close this issue, as you are describing expected behaviour.

[111andre111]

Ok, that's a good point. Thank you for pointing this out. Interesting approach. Good to know.
What I am just wondering is, why there don't leave out the -e parameter, because it actually happens the same - it's logging to the journal. Only if I configure the file settings, then I would get log files and wouldn't need to override the systemd parameter...

[simitt]

Thanks again for bringing this up. The behavior is inherited from libbeat though. You're very welcome to open an enhancement issue in beats for further discussions. I am going to close this one, as it is expected behavior and changes would need to be applied in libbeat first.