Skip to content

feat(log): emit program identity banner + module target on every line (closes #310)#320

Open
0xghost42 wants to merge 1 commit into
domcyrus:mainfrom
0xghost42:feat/310-log-program-info
Open

feat(log): emit program identity banner + module target on every line (closes #310)#320
0xghost42 wants to merge 1 commit into
domcyrus:mainfrom
0xghost42:feat/310-log-program-info

Conversation

@0xghost42
Copy link
Copy Markdown
Contributor

Why

Issue #310: the existing log file only carries timestamp + level + message, so a user looking at a long-running rustnet log has no direct way to confirm which binary, which version, and which pid produced the entries.

What

Two small changes in setup_logging:

  1. Module target on every line. Switch from LogConfig::default() to a ConfigBuilder with set_target_level(LevelFilter::Error), which tells simplelog to include the originating target (module path) on every log line.

    Before:

    2026-05-25 18:00:00 [INFO] Refreshing connections
    

    After:

    2026-05-25 18:00:00 [INFO] (rustnet_monitor::network::poll) Refreshing connections
    
  2. Startup banner with program identity. Emit one identifying line immediately after the writer is wired up:

    2026-05-25 18:00:00 [INFO] (rustnet_monitor::main) rustnet-monitor v1.3.0 starting (pid 12345)
    

    pkg_name and pkg_version come from env!("CARGO_PKG_NAME") / env!("CARGO_PKG_VERSION") so they stay correct when the binary is renamed or symlinked (i.e. not derived from argv[0]). The pid uses std::process::id().

Verification

$ cargo build              # clean
$ cargo clippy --all-targets -- -D warnings   # clean
$ cargo fmt --check        # clean
$ cargo test --lib         # 365 passed

No behavior change outside the log file format. Open to feedback if you'd prefer the banner phrased differently (e.g. include the BPF filter / interface in the startup line, or include the start timestamp explicitly even though simplelog already stamps each line).

Closes #310

…closes domcyrus#310)

Issue domcyrus#310: the existing log file only shows timestamp + level +
message, so a user looking at a long-running rustnet log has no
direct way to confirm which binary, which version, and which pid
produced the entries.

Two small changes in `setup_logging`:

1. Switch from `LogConfig::default()` to a `ConfigBuilder` with
   `set_target_level(LevelFilter::Error)`, which tells simplelog to
   include the originating `target` (module path) on every log line.
   So instead of just:

       2026-05-25 18:00:00 [INFO] Refreshing connections

   the user now sees which subsystem emitted the line:

       2026-05-25 18:00:00 [INFO] (rustnet_monitor::network::poll) Refreshing connections

2. Emit a one-line startup banner immediately after the writer is
   wired up:

       2026-05-25 18:00:00 [INFO] (rustnet_monitor::main) rustnet-monitor v1.3.0 starting (pid 12345)

   `pkg_name` and `pkg_version` come from `env!("CARGO_PKG_NAME")` /
   `env!("CARGO_PKG_VERSION")` so they stay correct when the binary
   is renamed or symlinked (i.e. not derived from `argv[0]`).

`cargo build`, `cargo clippy --all-targets -- -D warnings`,
`cargo fmt --check`, and `cargo test --lib` (365 pass) are all
clean. No behavior change outside the log file format.
Comment thread src/main.rs
// Check privileges BEFORE initializing TUI (so error messages are visible)
check_privileges_early()?;

info!("Starting RustNet Monitor");
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious with this and the one you've added further down we have two starting RustNet log lines, should they be combined.

@domcyrus
Copy link
Copy Markdown
Owner

@0xghost42 Thanks a lot for your PR, Ive added one minor comment which I think we should tackle prior merging this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

I like that this tool hase a logging functionality, but I am missing the program entry in the logs.

2 participants