{"record":{"id":"9081c5c4667c934c","repo":"neondatabase/neon","slug":"warning-disable-cores-setrlimit-failed-s","errorCode":null,"errorMessage":"WARNING: disable cores setrlimit failed: %s","messagePattern":"WARNING: disable cores setrlimit failed: (.+?)","errorType":"console","errorClass":null,"httpStatus":null,"severity":"warning","filePath":"pgxn/neon/neon_utils.c","lineNumber":138,"sourceCode":"/*\n * Disables core dump for the current process.\n */\nvoid\ndisable_core_dump()\n{\n\tstruct rlimit rlim;\n\n#ifdef WALPROPOSER_LIB\t\t\t/* skip in simulation mode */\n\treturn;\n#endif\n\n\trlim.rlim_cur = 0;\n\trlim.rlim_max = 0;\n\tif (setrlimit(RLIMIT_CORE, &rlim))\n\t{\n\t\tint\t\t\tsave_errno = errno;\n\n\t\tfprintf(stderr, \"WARNING: disable cores setrlimit failed: %s\", strerror(save_errno));\n\t}\n}\n\n#ifndef WALPROPOSER_LIB\n\n/*\n * On macOS with a libcurl that has IPv6 support, curl_global_init() calls\n * SCDynamicStoreCopyProxies(), which makes the program multithreaded. An ideal\n * place to call curl_global_init() would be _PG_init(), but Neon has to be\n * added to shared_preload_libraries, which are loaded in the Postmaster\n * process. The Postmaster is not supposed to become multithreaded at any point\n * in its lifecycle. Postgres doesn't have any good hook that I know of to\n * initialize per-backend structures, so we have to check this on any\n * allocation of a CURL handle.\n *\n * Free the allocated CURL handle with curl_easy_cleanup(3).\n *\n * https://developer.apple.com/documentation/systemconfiguration/1517088-scdynamicstorecopyproxies","sourceCodeStart":120,"sourceCodeEnd":156,"githubUrl":"https://github.com/neondatabase/neon/blob/8f60b04da47ffefe0e52bda2440134b42874eb75/pgxn/neon/neon_utils.c#L120-L156","documentation":"The neon Postgres extension calls setrlimit(RLIMIT_CORE, 0) at startup to suppress core dumps, because the process holds pageserver and WAL credentials that must not land on disk (the call is skipped only in WALPROPOSER_LIB simulation mode). If the syscall fails, typically EPERM in restricted sandboxes, only this warning is printed and startup continues; core dumps are then simply not guaranteed to be disabled.","triggerScenarios":"Running the neon extension or safekeeper components under seccomp or container profiles that deny setrlimit; LSM or runtime policies restricting rlimit changes; platforms with limited rlimit support.","commonSituations":"Hardened Kubernetes pods with restricted seccomp or AppArmor; gVisor or Kata sandboxed runtimes; CI containers with tightened privilege sets. Functionality is unaffected; only the core-dump policy is.","solutions":["No functional action needed; the warning is informational","To keep core suppression guaranteed, allow the setrlimit syscall in the container or seccomp profile","Alternatively disable core dumps at the orchestrator level (ulimit in the unit file, core pattern, securityContext)"],"exampleFix":null,"handlingStrategy":"fallback","validationCode":null,"typeGuard":null,"tryCatchPattern":null,"preventionTips":["Allow setrlimit in seccomp and container profiles for neon components","Set RLIMIT_CORE=0 or disable core dumps at the orchestrator so the in-process call is redundant","Treat repeated warnings in logs as an environment-hardening signal, not a fault"],"tags":["neon-extension","setrlimit","core-dumps","sandbox","libc","environment"],"backgroundTag":"setrlimit-permission-denied","analyzedSha":"8f60b04da47ffefe0e52bda2440134b42874eb75","analyzedAt":"2026-08-16T23:39:28.135Z","schemaVersion":2},"datasetVersion":"2026-08-17T04:17:16.089Z"}