[ https://issues.apache.org/jira/browse/KUDU-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16416134#comment-16416134 ]
Adar Dembo commented on KUDU-2377: ---------------------------------- This was originally reported in a Docker environment. After some testing, it appears that RLIMIT_NPROC is \-1 (unlimited) in basically any Docker container because they inherit ulimits from dockerd, and since dockerd runs as root, it gets RLIMIT_NPROC of \-1. That can be overridden with either \-\-default-ulimit (docker configuration file) or \-\-ulimit (docker run command line), but it's unlikely that users set either of those. > Server fails to start up when RLIMIT_NPROC is -1 > ------------------------------------------------ > > Key: KUDU-2377 > URL: https://issues.apache.org/jira/browse/KUDU-2377 > Project: Kudu > Issue Type: Bug > Components: server > Affects Versions: 1.7.0 > Reporter: Adar Dembo > Assignee: Adar Dembo > Priority: Blocker > Fix For: 1.8.0, 1.7.1 > > > Unlike RLIMIT_NOFILE, it would appear that RLIMIT_NPROC can be set to the > special value RLIM_INFINITY. This special value is represented as the integer > value -1, which means it's not safe for callers of Env::GetResourceLimit to > simply treat the returned value as a non-zero integer. > Currently GetThreadPoolThreadLimit (kserver.cc) has a perfect example of such > misbehavior; If I open a root shell, run `ulimit -o unlimited`, then try to > start a server, I get the following check failure: > {noformat} > I0326 13:00:33.053771 19813 env_posix.cc:1629] Not raising this process' > running threads per effective uid limit of 18446744073709551615; it is > already as high as it can go > F0326 13:00:33.053802 19813 threadpool.cc:106] Check failed: max_threads > 0 > (0 vs. 0) > *** Check failure stack trace: *** > *** Aborted at 1522094433 (unix time) try "date -d @1522094433" if you are > using GNU date *** > PC: @ 0x7fe5de4bd428 gsignal > *** SIGABRT (@0x4d65) received by PID 19813 (TID 0x7fe5d9421840) from PID > 19813; stack trace: *** > @ 0x7fe5e0207390 (unknown) > @ 0x7fe5de4bd428 gsignal > @ 0x7fe5de4bf02a abort > @ 0x7fe5df49a1d9 google::logging_fail() > @ 0x7fe5df49bb1d google::LogMessage::Fail() > @ 0x7fe5df49da03 google::LogMessage::SendToLog() > @ 0x7fe5df49b67a google::LogMessage::Flush() > @ 0x7fe5df49e3cf google::LogMessageFatal::~LogMessageFatal() > @ 0x7fe5df942bf2 kudu::ThreadPoolBuilder::set_max_threads() > @ 0x7fe5e0738fad kudu::kserver::KuduServer::Init() > @ 0x7fe5e0650a45 kudu::master::Master::Init() > @ 0x7fe5e067559d kudu::master::MiniMaster::Start() > @ 0x4b3bbb kudu::master::MasterTest::SetUp() > @ 0x7fe5e08d2477 testing::internal::HandleExceptionsInMethodIfSupported<>() > @ 0x7fe5e08c77f6 testing::Test::Run() > @ 0x7fe5e08c79a8 testing::TestInfo::Run() > @ 0x7fe5e08c7a85 testing::TestCase::Run() > @ 0x7fe5e08c8758 testing::internal::UnitTestImpl::RunAllTests() > @ 0x7fe5e08d2987 testing::internal::HandleExceptionsInMethodIfSupported<>() > @ 0x7fe5e08c7b5a testing::UnitTest::Run() > @ 0x7fe5e092c09a RUN_ALL_TESTS() > @ 0x7fe5e0929d88 main > @ 0x7fe5de4a8830 __libc_start_main > @ 0x47a429 _start > {noformat} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)