embedded PostgreSQL databaseが起動しなくてClouderaManagerがこける

ある日ClouderaManagerに入れなくなった。
/var/log/cloudera-scm-server以下のログを見るとDBに繋がっていないっぽい。
/var/log/cloudera-scm-server/db.log はこんな感じ。

FATAL:  could not create shared memory segment: Invalid argument
DETAIL:  Failed system call was shmget(key=7432001, size=8356855808, 03600).
HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.  You can either reduce the request size or reconfigure the kernel with larger SHMMAX.  To reduce the request size (currently 8356855808 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
        If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
        The PostgreSQL documentation contains more information about shared memory configuration.

共有メモリ（SHMMAX）が足りない、とのこと。
以前は起動できていたから、それ以降の変更が問題なのだろう。
SHMMAXやらpostgresql.confやらは変更した覚えなし。
やったことといえばvmwareをインストールしたことくらい。

色々探してみると/etc/init.d/vmwareにこんな箇所が。

shmmaxPath=/proc/sys/kernel/shmmax
shmmaxMinValue=268435456 # 256MB

〜略〜

      shmmax=`cat $shmmaxPath`

〜略〜

      if  ((  $shmmax < 1 )) || (( $shmmaxMinValue < 1 )) \
       || (( $shmmax < $shmmaxMinValue )) ; then
         echo "$shmmaxMinValue" > "$shmmaxPath"
         echo ""
         echo "Setting the max shared memory the system will allow to $shmmaxMinValue."
         echo ""
      fi

SHMMAXを書き換えている。
こいつが犯人だろう。
だが変だ。
書き換えの条件は「$shmmax < 256MB」の場合だ。
今これが真なら、8GB必要なClouderaManagerは以前から起動できなかったはずだ。

そこで$shmmaxを調べたところ、18446744073692774399が設定されていた。
でかい。
数値として比較するときにオーバーフローしているのかな？
/etc/sysctl.confにSHMMAXを搭載メモリと同じサイズで設定して再起動。
これでめでたく解決〜と思ったがそうではなかった。

ClouderaManagerは起動するようになったが、ServiceMonitorとHostMonitorにつながらないらしい。
とりあえずClouderaManagerから両者を手動で起動してみる。
どうやら正常に起動できたようだ。
それではエラーの出ているCloudera Management Serviceとクラスタを手動で再起動してみる。
できた。問題ないようだ。

めでたしめでたし。