[jira] [Commented] (KUDU-2377) Server fails to start up when RLIMIT_NPROC is -1

["Adar Dembo (JIRA)" <ji...@apache.org>]

    [ 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)