lib: warn once when process fd limit is very large

[Jafaral]

Each event_master_create() logged the same fd limit warning (e.g. zebra main plus dplane pthreads).

[mjstapp]

sure - but is the new message too gentle?

[greptile-apps]

Greptile Summary

This PR suppresses the repeated "FD Limit … is stupidly large" warning that fires once per event_master_create() call (main thread + dplane pthreads in zebra). It introduces a file-scoped static bool fd_limit_large_warned flag and gates zlog_warn() behind it, also lightly rewording the message.

• The "warn once" gate is a plain non-atomic read-modify-write on a shared boolean with no mutex or memory ordering guarantee; two threads racing through event_master_create() at startup could both observe the flag as false and each emit the warning.
• The message wording has been updated from "Is this what you intended?" to "Is this intentional?" for conciseness.

Confidence Score: 4/5

Safe to merge; worst case a duplicate warning is logged at startup when threads race.

The flag check-and-set is not protected by any synchronization primitive, so two threads racing through event_master_create() at daemon startup could both see the flag as unset and each emit the warning. This undermines the warn-once goal but has no functional impact beyond a duplicate log line.

lib/event.c — the fd_limit_large_warned flag and its unguarded check-then-set pattern.

Important Files Changed

Filename	Overview
lib/event.c	Introduces a static bool flag to suppress duplicate fd-limit warnings across multiple event_master_create() calls; flag is not protected against concurrent access, leaving a small window where the warning could fire more than once on parallel startup.

Sequence Diagram

sequenceDiagram
    participant Main as zebra main thread
    participant Dplane as dplane pthread
    participant EM as event_master_create()
    participant Flag as fd_limit_large_warned (static bool)

    Main->>EM: event_master_create("main")
    EM->>Flag: read false
    EM->>Flag: write true
    EM->>EM: zlog_warn emitted once

    Dplane->>EM: event_master_create("dplane")
    EM->>Flag: read true
    EM->>EM: warning suppressed

    Note over Main,Dplane: Race window concurrent startup
    Main-->>EM: event_master_create()
    Dplane-->>EM: event_master_create()
    EM-->>Flag: both read false simultaneously
    EM-->>Flag: both write true
    EM-->>EM: warning emitted TWICE

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
lib/event.c:771-775
**Non-atomic check-then-set on shared flag**

`fd_limit_large_warned` is a plain `static bool` with no synchronization. If two threads call `event_master_create()` concurrently (e.g., the zebra main thread and a dplane pthread racing at startup), both can observe `fd_limit_large_warned == false` before either writes `true`, causing the warning to fire twice — the exact scenario this PR aims to prevent. A `pthread_once` guard (reusing the existing `init_once` pattern already present in this file) or a C11 `_Atomic bool` would close the window.

_{Reviews (1): Last reviewed commit: "lib: warn once when process fd limit is ..." | Re-trigger Greptile}

[greptile-apps]

Non-atomic check-then-set on shared flag

fd_limit_large_warned is a plain static bool with no synchronization. If two threads call event_master_create() concurrently (e.g., the zebra main thread and a dplane pthread racing at startup), both can observe fd_limit_large_warned == false before either writes true, causing the warning to fire twice — the exact scenario this PR aims to prevent. A pthread_once guard (reusing the existing init_once pattern already present in this file) or a C11 _Atomic bool would close the window.

Prompt To Fix With AI

This is a comment left during a code review.
Path: lib/event.c
Line: 771-775

Comment:
**Non-atomic check-then-set on shared flag**

`fd_limit_large_warned` is a plain `static bool` with no synchronization. If two threads call `event_master_create()` concurrently (e.g., the zebra main thread and a dplane pthread racing at startup), both can observe `fd_limit_large_warned == false` before either writes `true`, causing the warning to fire twice — the exact scenario this PR aims to prevent. A `pthread_once` guard (reusing the existing `init_once` pattern already present in this file) or a C11 `_Atomic bool` would close the window.

How can I resolve this? If you propose a fix, please make it concise.

[Jafaral]

@greptile, that was intentional, i.e, no need for added complexity. worst case we get the log msg more than once as before.

[greptile-apps]

Fair enough — the race window is tiny and the worst case is harmless (an extra log line), so the added complexity isn't worth it. Thanks for the clarification!

Tip: You can give me more context with .greptile/rules.md so I get this right next time.

[Jafaral]

sure - but is the new message too gentle?

I figured we had that long enough! we can be gentle moving forward 😂

[choppsv1]

I get this warning when I run in some container environments, I have no idea what it means and it annoys me. Does this limit somehow adversely affect the operation of FRR? If it doesn't then we should just get rid of it IMO.

[choppsv1]

I get this warning when I run in some container environments, I have no idea what it means and it annoys me. Does this limit somehow adversely affect the operation of FRR? If it doesn't then we should just get rid of it IMO.

Apparently it does, as we need to allocate arrays based on it.

[mjstapp]

yes, it was used more before we did the epoll() conversion in the event/scheduling component; I think it's not used much otherwise.

I get this warning when I run in some container environments, I have no idea what it means and it annoys me. Does this limit somehow adversely affect the operation of FRR? If it doesn't then we should just get rid of it IMO.

Apparently it does, as we need to allocate arrays based on it.

[Jafaral]

I get this warning when I run in some container environments, I have no idea what it means and it annoys me. Does this limit somehow adversely affect the operation of FRR? If it doesn't then we should just get rid of it IMO.

It is annoying. One way to make it go away is to ulimit -n 100000