ExaBGP 5.0.8 ignores exabgp.log.destination from env-file and environment variables under systemd

[linecolumn]

ExaBGP 5.0.8 ignores exabgp.log.destination from env-file and environment variables under systemd

Environment

• ExaBGP version: 5.0.8 (installed via pip)
• OS: RHEL 10
• Python: system Python 3
• Service manager: systemd

Description

When running ExaBGP under systemd, logging configuration via both:

1. --env-file
2. environment variables

is ignored for exabgp.log.destination.

Despite explicitly setting a file destination, ExaBGP continues to log to stdout only.

Configuration

systemd unit (relevant parts)

ExecStart=/usr/local/bin/exabgp --env-file /etc/exabgp/exabgp.env /etc/exabgp/exabgp.conf

env file

[exabgp.log]
all = true
destination = /var/log/exabgp.log
level = INFO
enable = true

Reproduction steps

1. Create valid env file with log destination set to file

2. Start ExaBGP with:

   exabgp --env-file /etc/exabgp/exabgp.env /etc/exabgp/exabgp.conf
   

3. Verify effective config:

   exabgp --env-file /etc/exabgp/exabgp.env env
   

Expected behavior

[exabgp.log]
destination = '/var/log/exabgp.log'
all = true

ExaBGP should write logs to /var/log/exabgp.log.

Actual behavior

[exabgp.log]
destination = 'stdout'
all = false

Logs are only emitted to stdout (captured by journald), and no file is written.

Additional observations

• Using systemd Environment= with dotted variables is not possible due to systemd restrictions
• Using underscore variants (exabgp_log_destination) does not affect ExaBGP behavior
• Passing variables via /usr/bin/env exabgp.log.destination=... also does not redirect logs
• File permissions and paths verified as correct
• Manual writes to the same file by the exabgp user succeed

Impact

• Unable to use ExaBGP’s native file logging under systemd
• Forces reliance on systemd logging instead of application-level logging
• Makes log configuration inconsistent with documentation

Notes

The CLI documentation indicates that:

exabgp.log.destination = <filename>

should control file logging, but this appears to be ignored in this setup.

Unclear whether:

• env-file parsing is broken
• logging subsystem ignores file destination under systemd
• underscore environment variable mapping is incomplete

[thomas-mangin]

Thank you for the detailed report, you were right on all counts.

There were two bugs stacked on top of each other, which is why nothing you tried worked.

I asked Claude to investigate and here is what transpired:

The first bug is the worst and it is the reason --env-file appeared to be completely ignored. When ExaBGP starts, src/exabgp/debug/report.py was building a diagnostic info string at module load time, and that string included a call to Env.iter_env(). That call forces the environment subsystem to initialise using whatever ENVFILE is at that moment, which is the default path. By the time main() gets around to processing --env-file and updating the path, it is too late: the environment is already locked in and the second setup() call is a no-op. So your env file was parsed, never. Your expected output showing destination = 'stdout' and all = false is exactly the built-in defaults, which confirms it.

The fix is to build that diagnostic lazily, only when an exception is actually being reported. It has no business running at import time.

The second bug is that file logging has been quietly broken for a while. In src/exabgp/logger/option.py, the destination parser only accepted stdout, stderr, syslog, or file:. A bare path like /var/log/exabgp.log would silently fall back to stdout with no warning. And even if you had used the file: prefix, it still would not have worked: the actual file-handler setup code was commented out (I suspect it has been that way since a logger rewrite), so the logger would have ended up as None and the first log call would have crashed. Nobody noticed because the fallback to stdout hid everything.

I got Claude to rewrite the destination handling to accept:

• stdout, stderr, syslog as before
• host: for remote syslog
• file: as before
• A bare absolute path, or a ~-expanded path, so your config works as you wrote it

Anything else now prints a visible warning instead of silently falling back. And the file-handler wiring is actually there, using the RotatingFileHandler that was already in the handler module but never connected. If the file cannot be opened, it warns and falls back to stdout cleanly.

Both fixes are in on 5.0 and main, and will be in the next release. Your env file as originally written should work as-is, no prefix needed, and exabgp_log_destination=/var/log/exabgp.log via systemd Environment= will/should work too (that path goes through the same code).

Thanks again for the careful write-up, the reproduction steps and the "what I already tried" section made diagnosing this much faster.

If you can confirm that it now works for you, I will push another release.

[linecolumn]

Thank you for addressing this issue so quickly.

Waiting for v5.0.9 to test it out.

[thomas-mangin]

5.0.9 is out on PyPI: https://pypi.org/project/exabgp/5.0.9/

pip install --upgrade exabgp and your env file as originally written should work as-is. Please let me know if it does not.

[linecolumn]

Upgraded.

I see log entries in specified filepath, but not all of the entries.

Some are in the file:

$ tail -f exabgp.log 
11:24:03 653355 welcome         Thank you for using ExaBGP
11:24:03 653355 cli control     named pipes for the cli are:
11:24:03 653355 cli control     to send commands  /run/exabgp.in
11:24:03 653355 cli control     to read responses /run/exabgp.out
11:24:03 653355 outgoing-1      outgoing-1 10.10.10.10-10.10.10.1, closing connection
11:24:03 653355 outgoing-1      connection to 10.10.10.1 closed
11:24:03 653355 outgoing-2      outgoing-2 10.10.10.10-10.10.10.1, closing connection
11:24:03 653355 outgoing-2      connection to 10.10.10.1 closed

And some are in the journal (I know how to fix this error tho):

Apr 12 11:25:44 10.10.10.10 healthcheck-ipvs4[653358]: Check command was unsuccessful: 1
Apr 12 11:25:44 10.10.10.10 healthcheck-ipvs4[653358]: send announces for DOWN state to ExaBGP
Apr 12 11:25:44 10.10.10.10 exabgp[653355]: ================================================================================
Apr 12 11:25:44 10.10.10.10 exabgp[653355]: WARNING: Non-callable log message detected!
Apr 12 11:25:44 10.10.10.10 exabgp[653355]: ================================================================================
Apr 12 11:25:44 10.10.10.10 exabgp[653355]: Source: configuration
Apr 12 11:25:44 10.10.10.10 exabgp[653355]: Level: ERROR
Apr 12 11:25:44 10.10.10.10 exabgp[653355]: Message type: str
Apr 12 11:25:44 10.10.10.10 exabgp[653355]: Message preview: the route family (ipv6/unicast) is not configured on neighbor neighbor 10.10.10.1 local-ip 10.10...
Apr 12 11:25:44 10.10.10.10 exabgp[653355]: All log messages MUST be wrapped in lambda for lazy evaluation:
Apr 12 11:25:44 10.10.10.10 exabgp[653355]:   WRONG: log.error("message", "configuration")
Apr 12 11:25:44 10.10.10.10 exabgp[653355]:   RIGHT: log.error(lambda: "message", "configuration")
Apr 12 11:25:44 10.10.10.10 exabgp[653355]: ================================================================================

Ideally, all log entries would go to the file.

[thomas-mangin]

The remaining issue where the non-callable log warning was going to stderr (and therefore to the journal) instead of the configured log file is now fixed on 5.0 (2dfc2b8). All log calls that were passing plain strings instead of lambdas have also been corrected.

Both fixes will be in the next release.