How can I configure Erlang's error_logger to persist logs to a file for post‑mortem analysis of a failed deployment?

Configuring Persistence for error_logger

To redirect Erlang's error_logger output to a file that survives node termination, use the error_logger:logfile/1 function. This redirects the standard error output to the specified file path.

error_logger:logfile("error.log").

Write Semantics and Persistence

Based on standard error_logger behavior in legacy OTP versions:

• Append vs. Truncate: error_logger:logfile/1 opens the file in append mode. It does not truncate existing logs upon node restart, which is critical for post-mortem analysis across multiple crash cycles.
• Flushing: The logger generally relies on the operating system's file buffering. While it attempts to write entries promptly, it does not guarantee a synchronous fsync after every single entry. In the event of a catastrophic OS kernel panic, the very last few entries may be lost, but for standard Erlang VM crashes or process terminations, the buffered data is typically flushed by the OS.

Handler Installation and Boot Timing

If you are using error_logger:add_report_handler/2 to implement a custom logging strategy, the timing of the call is critical:

• Boot Script: To capture early boot events—such as failures in application startup or configuration loading—the handler must be installed in the boot script or via the sys.config file.
• Post-Startup: Adding a handler after the application has started is safe and will not crash the node, but you will have a "blind spot" for any errors that occurred during the initialization phase of the VM and the application.

Verification Steps

To verify that your configuration is active and persisting data, run the following in your shell:

1. Set the log file: error_logger:logfile("debug_test.log").
2. Trigger a test error: error_logger:error_msg("Verification test entry").
3. Check the filesystem: cat debug_test.log

Important Version Note

The error_logger module is considered legacy in Erlang/OTP 21 and later. If you are using a modern version, it is highly recommended to migrate to the logger module, which provides more robust handler configurations and built-in support for log rotation to prevent disk exhaustion.

Diagnostic Detail Needed: Please specify your Erlang/OTP version. If you are on OTP 21+, the recommendation shifts entirely toward the logger framework for guaranteed persistence and rotation.