2015年7月1日水曜日

git(GitLab)ユーザーのrubyプロセスが100%に近くなる

gitlab_questionある日突然git fetchが失敗するので調べたときの覚書。

環境: CentOS 6.6, GitLab 7.11.4 → 7.12.0

 

Mac上でgitコマンドを打つと下記エラー
$ git fetch origin

remote: Counting objects: 48, done.
remote: fatal: unable to create thread: Resource temporarily unavailable
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header

あれ?と思ってもう一度実行
$ git fetch origin

[FATAL] failed to allocate memory
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

SSH接続で既に失敗する。

サーバー側でSSHデーモンを再起動しようとすると「fork: メモリを確保できません」とエラーになった。

topコマンドを打つとgitユーザーがrubyコマンドを一生懸命実行していてcpu使用率が100%になっている。

試しにGitLabサービスを止めてみるとCPU100%状態が収まったので、GitLabが原因だと判明。
# gitlab-ctl stop

もう一度GtiLabを実行しながらログを確認。
# gitlab-ctl start
# tail -f /var/log/gitlab/unicorn/unicorn_stderr.log

/opt/gitlab/embedded/service/gitlab-rails/config/initializers/gitlab_shell_secret_token.rb:13:in `write': Permission denied @ rb_sysopen - /opt/gitlab/embedded/service/gitlab-rails/.gitlab_shell_secret (Errno::EACCES)

なんかエラーを吐き続けてる。

書き込みに失敗している様子。

プログラムを確認
# more /opt/gitlab/embedded/service/gitlab-rails/config/initializers/gitlab_shell_secret_token.rb

「Gitlab.config.gitlab_shell.secret_file」を設定すれば良さそう。

 

ここでGitLabをYUM経由で7.12.0にアップデートしたけど、reconfigureしてないと気づいてやってみる。
# gitlab-ctl reconfigure
# gitlab-ctl restart

。。。直ったっぽい。

 

< Related Posts >

コメントを投稿
Related Posts Plugin for WordPress, Blogger...

Blog Archives