Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 567
    • Issues 567
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 94
    • Merge requests 94
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • BINDBIND
  • Issues
  • #3563
Closed
Open
Issue created Sep 26, 2022 by Stacey Marshall@sjm

named fails to start on Solaris 11.4.48: unexpected error: pipe() failed: too many files

BIND 9.16.33 seen to fail early during startup (before reading named.conf) on systems with a large number of CPU's; greater than 510 in testing. The named process would log the following error:

socket.c:3561: unexpected error:
pipe() failed: Too many open files

Looking at the processes file descriptor limits with plimit or pfiles the process is seen to be limited to 4095 initially. The same was the case with BIND 9.11.x, however that called setrlimit(RLIMIT_NOFILE, &arg) earlier on during startup, this same call is not seen with 9.16.29 version, through 9.16.33.

Review of source finds that a guard around an earlier call in named_os_adjustnofile() prevents Solaris build of 9.16.x from making that call. This simple patch to the guard addresses the issue:

diff -r 598de125ad73 bin/named/unix/os.c
--- a/bin/named/unix/os.c	Thu Sep 15 07:02:36 2022 -0700
+++ b/bin/named/unix/os.c	Thu Sep 15 07:10:27 2022 -0700
@@ -485,13 +485,15 @@
 
 void
 named_os_adjustnofile(void) {
-#if defined(__linux__)
+#if defined(__linux__) || defined(__sun)
 	isc_result_t result;
 	isc_resourcevalue_t newvalue;
 
 	/*
 	 * Linux: max number of open files specified by one thread doesn't seem
 	 * to apply to other threads on Linux.
+	 * Sun: restriction needs to be removed sooner when hundreds of CPUs
+	 * are available.
 	 */
 	newvalue = ISC_RESOURCE_UNLIMITED;
 
@@ -499,7 +501,7 @@
 	if (result != ISC_R_SUCCESS) {
 		named_main_earlywarning("couldn't adjust limit on open files");
 	}
-#endif /* if defined(__linux__) */
+#endif /* if defined(__linux__) || defined(__sun) */
 }
 
 void

Note: use of __sun here (rather than __sun__) for Studio compatibility.

Workaround for systems without the patch is to use named(8) -n option to limit the number of threads.

Tracked at Oracle as bug 34589558

Assignee
Assign to
Time tracking