[
https://issues.apache.org/jira/browse/KUDU-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16884186#comment-16884186
]
Ritwik Yadav commented on KUDU-1334:
------------------------------------
Talking about IPv6, the loopback address is simply ::1/128 in CIDR notation.
Therefore, there is only one possibility. However, with IPv4 loopback addresses
were denoted by 127.0.0.1/8 so we had 2^24 different choices.
There is a possible workaround that IPv4 addresses could be used as IPv6 as
detailed here:
[https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.hale001/ipv6d0031001726.htm]
> Support pid_max > 16 bits in the mini cluster
> ---------------------------------------------
>
> Key: KUDU-1334
> URL: https://issues.apache.org/jira/browse/KUDU-1334
> Project: Kudu
> Issue Type: Improvement
> Components: test
> Affects Versions: 0.5.0
> Reporter: Jean-Daniel Cryans
> Assignee: Alexey Serbin
> Priority: Major
> Fix For: 1.6.0
>
>
> Pretty much anybody running on newer machines/platforms will hit this while
> running the unit tests:
> {noformat}
> I0216 11:27:23.617383 110702 external_mini_cluster.cc:582] Started
> /home/stack/apache-kudu-incubating-0.7.0/build/rc/bin/kudu-master as pid
> 110706
> F0216 11:27:23.617473 110702 external_mini_cluster.cc:258] Check failed: p
> <= MathLimits<uint16_t>::kMax (110702 vs. 65535) Cannot run on systems with
> >16-bit pid
> *** Check failure stack trace: ***
> {noformat}
> Having this limitation was fine but now it's something everybody hits.
> The workaround is running this:
> {noformat}
> echo "32768" > /proc/sys/kernel/pid_max
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
