Sanity-check open-fd limits at startup and cap if needed.

This triggers a reporter warning when Zeek adjusts the limit, in the absence of
any ZEEK_NOFILE_MAX configuration. (With ZEEK_NOFILE_MAX, it's clear the user is
aware of the tuning mechanism and the warning seems unnecessary.)

This adjustment will happen by default in Docker environments until libkqueue
gets fixed or containerd changes its default-uncapped fd limit behavior, and
prevents libkqueue from needlessly allocating gigabytes of memory.

mheily/libkqueue#153
moby/moby#38814

src/zeek-setup.cc

@@ -491,6 +491,15 @@ SetupResult setup(int argc, char** argv, Options* zopts) {
     if ( options.run_unit_tests )
         options.deterministic_mode = true;
 
+    // Cap the allowable open file descriptor limits. We do this primarily to
+    // hedge against libkqueue's allocate-state-for-every-possible-fd behavior,
+    // which can lead to gigabytes of memory in high-max environments, like
+    // containerd's default. This needs to happen before we create the iosource
+    // manager, which initializes kqueue.
+    //
+    // For context see: https://github.com/mheily/libkqueue/issues/153
+    auto nofile_updates = util::nofile_cap_limits();
+
     auto stem = Supervisor::CreateStem(options.supervisor_mode);
 
     if ( Supervisor::ThisNode() ) {
@@ -690,6 +699,11 @@ SetupResult setup(int argc, char** argv, Options* zopts) {
     if ( options.print_usage )
         usage(argv[0], 0);
 
+    // Now that we're past any help output, warn if we reduced the fd limits:
+    if ( nofile_updates.show_warning() )
+        reporter->Warning("reduced open file descriptor limits (soft/hard %lu/%lu -> %lu/%lu)", nofile_updates.orig_cur,
+                          nofile_updates.orig_max, nofile_updates.new_cur, nofile_updates.new_max);
+
     init_event_handlers();
 
     md5_type = make_intrusive<OpaqueType>("md5");