狛ログ

オフィス狛 技術部です。

GitLab のインストール・設定シリーズ第３回目の今回は、Git リポジトリの移行を行います。
（移行元と移行先はサーバー（EC2インスタンス）が別）

その他の記事は、以下をご覧下さい。
第１回（AWS EC2 に GitLab をインストールする）
第２回（AWS EC2 に GitLab をインストールする（メールの送信テスト編））

では、早速Git リポジトリの移行を始めて行こうと思います。

１）GitLab にリポジトリ（プロジェクト）を作成する。

作成の手順は記載しませんが、前もって移行するリポジトリと同じ名前で、
GitLab プロジェクト（＝リポジトリ）を作成しておく必要があります。

ちなみに、GitLab では、ユーザー、またはグループに属する形でプロジェクトが作成されます。
なので弊社の場合、共有リポジトリ用グループ（例：hogehoge-dev）を作成し、
開発者用のプロジェクトは全て hogehoge-dev に属する様に作成しています。

※あくまで置き場所として用意しているだけなので、権限設定に関しては、
別のグループ等を作成し、プロジェクト単位にグループへの権限付与を行なっています。

以降の説明を簡単にする為に、各設定の名称を以下と仮定します。
　・旧Gitが存在しているサーバー　：　old.hoge.co.jp
　・移行したいリポジトリ名　：　RipoTest.git
　・GitLab（新Git）が存在しているサーバー　：　new.hoge.co.jp
　・GitLab のグループ　：　hogehoge-dev
　・GitLab のプロジェクト名　：　RipoTest

２）旧リポジトリをクローンする

続いて旧リポジトリをクローンします。
（今回、作業は、ローカル（Mac）側のターミナルで行なっています。）
sshで接続するので、旧サーバー側の鍵が必要になります。
鍵は、Macだと「/Users/mac_user/.ssh」に格納します。
※[mac_user]は、現在Macにログインしているユーザーです。

そして、コマンドを簡略化させる為に、同じディレクリに「config」というファイルを作成し、

Host config_name_1
  User connect_user
  HostName old.hoge.co.jp
  IdentityFile ~/.ssh/old_hoge_key_name

上記の内容を記述します。

　Host　：　コマンドに含める簡略名になります。　
　User　：　接続するサーバーのユーザー
　HostName　：　接続するサーバー
　IdentityFile　：　使用する鍵の場所

これで準備が出来たので、早速クローンします。

$ git clone --mirror ssh://config_name_1/RipoTest.git

「mirror」を付ける事によって、履歴を含めたリポジトリのバックアップを取る感じでクローン出来ます。

３）GitLab（新Git）へプッシュする

続いて、先程クローンしたリポジトリをGitLab（新Git）へプッシュします。
こちらも先程と同じ様に、「config」を設定します。

Host config_name_2
  User git
  HostName new.hoge.co.jp
  IdentityFile ~/.ssh/new_hoge_key_name

※GitLabをインストールした時に、「git」ユーザーが作成されています。

これで準備が出来たので、早速プッシュします。

git push --mirror ssh://config_name_2/hogehoge-dev/RipoTest.git

「mirror」を付けること、そして、GitLab のグループ名をリポジトリ名の前に付ける事を忘れずに。

これで大抵のリポジトリは問題無くプッシュ出来るのですが、リポジトリの容量が大きいと・・・

Counting objects: 7400, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6246/6246), done.
Writing objects: 100% (7400/7400), 558.97 MiB | 6.24 MiB/s, done.
Total 7400 (delta 2794), reused 3512 (delta 452)
remote: fatal: Out of memory, malloc failed (tried to allocate 228733096 bytes)
error: unpack failed: index-pack abnormal exit
To ssh://config_name_2/hogehoge-dev/RipoTest.git
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'ssh://config_name_2/hogehoge-dev/RipoTest.git'

と、エラーになる事があります。
これ、中々解決出来ず、ちょっとハマったのですが、
結論から言うと、プッシュ先（ここで言うとGitLabがインストールしてある「new.hoge.co.jp」）のメモリを増やす事で解決しました。（*1）

*1) プッシュ先のEC2 インスタンスを「t2.medium」から「t2.large」に一時的に変更しました。
弊社の場合、プッシュが全て終わったら、「t2.medium」へ戻しています。
「t2.large」は料金が高いので・・・。

これでリポジトリの移行が完了です。

オフィス狛 技術部です。

弊社は Codeigniter を使ってWebシステムを作る事が多いのですが、
開発（ローカル）環境で作成したプロジェクトをLinuxサーバへ配置し、
いざURLに接続・・・と言う時に、

Fatal error: Arrays are not allowed as constants

が発生する事が多いです。

原因も分かっているので、毎回同じ対応するのですが、
とりあえず記録として残しておこうと思います。

まず、エラーの内容ですが、直訳でも通じる程シンプルで、
「配列は定数として使えませんよ」と言う事です。

配列を定数として使えるのは PHP 5.6 からで、
その前のバージョンでは使用出来ません。

Linux系のサーバーだと、デフォルトが PHP 5.5 というのが多くて、
毎回、サーバーに配置してから気付く、という感じです。

対処方法としては、PHPをバージョンアップさせるか、
それが無理なら、配列を定数として使う事を諦めるしかありません。

今回は、PHP のバージョンアップの手順を備忘録も兼ねて、残しておこうと思います。
なお、以降の手順は CetnOS の場合を想定しています。

１）現在のPHPのバージョンを確認する

何はともあれ、まずは現在のPHPのバージョンを確認します。

$ php -v
PHP 5.5.38 (cli) (built: Nov  9 2016 17:25:01) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies

やはりバージョンは5.5 です。

２）異なるバージョンのPHPをインストールする

次は、現状のPHPとは異なるバージョンのPHPをインストールします。
今回は、PHP 5.6 をインストールします。

$ yum -y --enablerepo=epel,remi,remi-php56 install php56

これでインストールは出来たのですが、PATHは通っていない状態なので、下記を実行します。

$ source /opt/remi/php56/enable

ちなみに、「/opt/remi/php56/enable」の中身は、こんな感じです。

export PATH=/opt/remi/php56/root/usr/bin:/opt/remi/php56/root/usr/sbin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/opt/remi/php56/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
export MANPATH=/opt/remi/php56/root/usr/share/man:${MANPATH}

次はphpコマンドのリンク先を変えていきます。
現状のリンク先を確認すると、

$ ls -lrt /usr/bin/php
lrwxrwxrwx. 1 root root 14 11月 15 21:42 /usr/bin/php -> /usr/bin/php55

現状はPHP 5.5にリンクされている事が分かります。
では、一旦リンクを外して、PHP 5.6へリンクするように変更します。

$ unlink php
$ sudo ln -s /usr/bin/php56 /usr/bin/php

正しく変更されているか確認します。

$ ls -lrt /usr/bin/php
lrwxrwxrwx. 1 root root 14 12月  3 12:35 /usr/bin/php -> /usr/bin/php56
$ php -v
PHP 5.6.28 (cli) (built: Nov  9 2016 06:57:19) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

これで、Fatal error: Arrays are not allowed as constants が発生しなくなるはずです。

オフィス狛 技術部です。

前回 、AWS EC2 に GitLab をインストールしましたが、
メールの送信設定について補足しておきたいと思います。
GitLabでは、ユーザーを作成したり、ユーザー情報を更新したりすると、
該当のユーザーへメールが送信されます。
前回、メール送信の設定については説明しましたが、送信テストの実施方法について触れていませんでした。
実際にユーザーを作ったり、更新しないとメールのテストが出来ないのは不便すぎますからね。

メールテスト送信の手順

まずは、以下のコマンドで、コンソールを起動します。（起動まで、ちょっと時間掛かります）

sudo gitlab-rails console

続いて以下コマンドでメールをテスト送信します。

Notify.test_email('xxxx@hoge.co.jp', 'Message Subject', 'Message Body').deliver_now

はい、これだけです。
１番目の引数が、送信先のメールアドレス、
２番目の引数が、メールの件名、
３番目の引数が、メールの本文です。

これで送信出来ない場合は、どこか設定が間違っている、という事になります。

オフィス狛 技術部です。

弊社は、今まで Git へのアクセス制御は Gitolite を使用していました。
それでも特に困ってはいなかったのですが、
Pull Request（Merge Request） による管理をしたい、というのと、
Slack との連携を簡単にしたい、という事で、
Amazon EC2（OS は Amazon Linux）に GitLab をインストールして、
今ある Git リポジトリを移行する事にしました。

以降がインストールの方法です・・・と言いたいところですが、
本家サイトに、丁寧にインストール方法が記載されているので、
本家サイトの補足を記載していこうと思います。

※本家サイトには Amazon Linux 用の説明が無く、
一番近いのが CentOS なので、その辺の違いも書いていきます。

１）必要な依存ライブラリのインストールと設定

（本家サイト： Install and configure the necessary dependencies）

本家サイトでは

sudo yum install curl policycoreutils openssh-server openssh-clients
sudo systemctl enable sshd
sudo systemctl start sshd

となっていますが、
Amazon Linux は既に該当プラグインが設定されているので、この手順はスルーします。

続いて、GitLab からのメール送信する為の設定になります。
本家サイトの通り、以下のコマンドでインストールを行います。

$ sudo yum install postfix

続いて、postfix を有効にします。
本家サイトでは、

sudo systemctl enable postfix
sudo systemctl start postfix

となっていますが、
Amazon Linux には既に sendmail がインストールされているので、
sendmail を無効にする必要があります。

$ sudo /etc/init.d/postfix stop
$ sudo /etc/init.d/sendmail stop
sm-client を停止中:                                        [  OK  ]
sendmail を停止中:                                         [  OK  ]
$ sudo /etc/init.d/postfix start
postfix を起動中:                                          [  OK  ]

ついでに、メールの自動起動設定を変更しておきます。

$ sudo chkconfig postfix on
$ sudo chkconfig sendmail off

続いて、MTAも切り替えます。

$ sudo alternatives --config mta

2 プログラムがあり 'mta' を提供します。

  選択       コマンド
-----------------------------------------------
*+ 1           /usr/sbin/sendmail.sendmail
   2           /usr/sbin/sendmail.postfix

Enter を押して現在の選択 [+] を保持するか、選択番号を入力します:2

念の為、設定の確認をしておきます。

$ alternatives --display mta
mta - ステータスは手動です。
リンクは現在 /usr/sbin/sendmail.postfix を指しています。

２）GitLab のインストール

（本家サイト： Add the GitLab package server and install the package）

ようやくGitLab のインストールです。ここは本家サイト通り進めます。

$ curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
$ sudo yum install gitlab-ce

３）GitLab の設定と開始

（本家サイト： Configure and start GitLab）

後は、「gitlab-ctl reconfigure」して完了なのですが、
その前に、メールの設定を行っておきます。

※ ここからは、Amazon SES の設定が完了している事を前提とします。

以下のコマンドで、設定ファイルを開きます。

$ sudo vi /etc/gitlab/gitlab.rb

設定箇所は、本家サイトの SMTP setting - Amazon SES に詳しく書いてあります。

★その他、変更した箇所
SMTPの設定以外でも、external_url は自サイトのドメインへ、
gitlab_rails['time_zone'] はデフォルトが UTC になっているので、 Asia/Tokyo に変えました。

ここまでで、設定は完了したので、以下のコマンドで変更内容を反映させます。

$ sudo gitlab-ctl reconfigure

４）GitLab へログイン

（本家サイト： Browse to the hostname and login）

いざ、external_url に設定したURLに接続すると・・・


画面が表示されました。
デフォルトのユーザーが「root」で作られているので、
初めはそのユーザーでログインすることになります。
（まずはパスワード設定）

パスワードを設定してログインすると・・・・


おっと 502 エラーに。

調べて見ると、どうやらサーバーのメモリが足りないようです。

GitLab の構築には、1GBのメモリが推奨されているようなので、
EC2 インスタンスは「t2.small」にしたのですが・・・

とりあえず、「t2.medium」に変更した後、再度ログインしたところ上手くいきました。
（こういうスケールアップが簡単に出来るのが、AWS の良いところですね。）

ここまでで、インストール・設定・起動が完了したので、次回は、Git リポジトリの移行を行いたいと思います。

次回：AWS EC2 の GitLab へリポジトリを移行する

オフィス狛 技術部です。

前回（Redmineのバージョンアップ 2.5 → 3.3 その１）でようやく前準備が出来たので、
今回は Redmine 自体のバージョンアップを進めて行きます。

１）Redmine の本体をダウンロード・配置

まず、本家サイトから、 redmine-3.3.1.tar.gz をダウンロードします。

Redmineのインストールディレクトリ（ /var/lib ）に展開します。

$ tar xvf redmine-3.3.1.tar.gz
$ sudo mv redmine-3.3.1 /var/lib/

ディレクトリを /var/lib へ移動します。

$ cd /var/lib

前バージョンの設定ファイルを新バージョンの config ディレクトリにコピーします。

$ cp -p redmine/config/configuration.yml redmine-3.3.1/config
$ cp -p redmine/config/database.yml redmine-3.3.1/config

前バージョンに添付したファイルを新バージョンへコピーします。

$ cp -pr redmine/files redmine-3.3.1

※今回はプラグインを前もって全て削除しているので必要ありませんが、
削除していない場合は、プラグインも新バージョンへコピーする必要があります。

※自分で追加したテーマも新バージョンでも使いたい場合はコピーする必要があります。
今回は、アップグレード後に改めてテーマを入れる予定なので、旧バージョンからの移行はしていません。

２）アップグレード

新バージョンのディレクトリに移動します。

$ cd /var/lib/redmine-3.3.1

インストールを実施します。

$ bundle install --without development test

ここでエラーが出ました。

Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.
(中略)
/usr/bin/ld: -lmysqlclient が見つかりません
collect2: error: ld returned 1 exit status
make: *** [mysql2.so] エラー 1
(中略)
An error occurred while installing mysql2 (0.3.21), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.3.21'` succeeds before bundling.

共有ライブラリが見つからない、と怒られています。
というわけで、共有ライブラリへのリンクを作ります。

$ sudo ln -s /usr/lib64/mysql/libmysqlclient.so.18.0.0 /usr/lib64/libmysqlclient.so

再度インストールを実行します。

$ bundle install --without development test
Your bundle is complete!
Gems in the groups development and test were not installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.

今度は成功しました。

続いて鍵の生成を行います。

$ bundle exec rake generate_secret_token
rake aborted!
LoadError: incompatible library version - /home/ofkomamanage/.gem/ruby/2.0/gems/nokogiri-1.6.8.1/lib/nokogiri/nokogiri.so

またエラーになりました。

足りないライブラリがあるようなので、
ここで一度、必要なライブラリをインストールします。（パスの指定が必要です）

$ bundle install --path=vendor/bundle

再度、コマンド（鍵の生成）を実行します。

$ bundle exec rake generate_secret_token

３）データベースの更新

マイグレーションを行います。

$ bundle exec rake db:migrate RAILS_ENV=production

※今回はプラグインを前もって全て削除しているので必要ありませんが、
削除していない場合、以下のコマンドにてプラグイン分のマイグレーションも行う必要があります。

$ bundle exec rake redmine:plugins:migrate RAILS_ENV=production

４）クリーン

キャッシュとセッションのクリアを行います。

$ bundle exec rake tmp:cache:clear tmp:sessions:clear

５）Passenger のセットアップ

Passenger は、Rails を使って作られたWebアプリケーションをApacheで動かす為のモジュールです。
では、早速 Passenger をインストールします。

$ rbenv exec gem install passenger --no-rdoc --no-ri

セットアップを続けます。

$ passenger-install-apache2-module

Please edit your Apache configuration file, and add these lines:

   LoadModule passenger_module /home/officekoma/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/passenger-5.0.30/buildout/apache2/mod_passenger.so
   
     PassengerRoot /home/officekoma/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/passenger-5.0.30
     PassengerDefaultRuby /home/officekoma/.rbenv/versions/2.3.1/bin/ruby
   

Apacheの「conf.d」ディレクトリ内に、「passenger.conf」というファイルを作成し、
上記の「LoadModule passenger_module」以降の部分をそのまま貼り付けます。

６）Webサーバー（Apache）の設定変更と再起動

この辺は、各環境によって設定方法は変わってくると思いますが、
弊社の場合、Redmineが動いているサーバーでは、他のWebシステムは動いていません。
なので、DocumentRoot を「/var/lib/redmine/public」から、
「/var/lib/redmine-3.3.1/public」に直接変更し、再起動します。

$ sudo /etc/init.d/httpd restart

いざ接続してみると、「Internal Server Error」に・・・。
ログを確認してみます。

DEPRECATION WARNING: You didn't set `secret_key_base`. Read the upgrade documentation to learn more about this new config option. (called from validate_secret_key_config! at /home/officekoma/.gem/ruby/2.0/gems/railties-4.2.7.1/lib/rails/application.rb:530)

Secret Key を設定しなくてはいけないようです。

$ rake secret

上記コマンドを実行すると、長い文字列が表示されるので、それをコピーしておきます。
そして、下記コマンドで Secret Key 設定ファイルを開きます。

$ vi /var/lib/redmine-3.3.1/config/initializers/secret_token.rb

下記「xxxxxxxxx」の部分を先程コピーした Secret Key で置き換えます。

RedmineApp::Application.config.secret_key_base = 'xxxxxxxxx'

これでエラーは出なくなりました。

長い道のりでしたが、これでRedmineのバージョンアップは完了です。
（これでも思ったよりはスムーズに行きました。）
後はしばらく稼働させて様子見です。

オフィス狛 技術部です。

弊社のRedmineは、平日は終日使用されていて、
バージョンアップを行うタイミングは土日に限られてしまうのですが、
以前実施した時に、見事に失敗して、そこからずっと再実施するタイミングがありませんでした。

今回、ようやく実施出来るタイミングを作れたので、
今度は成功するまで頑張ってみようと思います。

１）作業前バックアップ

弊社Redmineは、AWS(Amazon Web Services)上に構築しているので、
作業前のバックアップも、各データごとに取得する訳ではなく、
マシンイメージ（AMI）ごと取得しています。
よって、細かいバックアップの手順は記載しません。
必要であれば、本家サイトを参照して下さい。

２）バージョンアップ前準備（プラグインの削除）

プラグインがRedmineの新しいバージョンに対応していないと、
バージョンアップに失敗する事がある、と聞いていたので、
念の為、プラグインは削除しておこうと思います。

現在使用しているのは以下の二つです。（思ったより少なかった）

Parent issue filter plugin (parent_issue_filter)
　→チケットを親チケットでフィルタ出来るプラグインです。
　　Redmineの3.1から、プラグインなしでも親チケットによるフィルタが実装されたようなので、
　　このプラグインは削除しようと思います。

Redmine Gantt With Date plugin (redmine_gantt_with_date)
　→ガントチャートに日付を表示するプラグインです。
　　こちらはRedmine3.2からプラグインなしでも日付が表示されるようになったようなので、
　　このプラグインも削除しようと思います。

削除は、下記のコマンドを実行します。

$ rake redmine:plugins:migrate  NAME=xxxxxx VERSION=0 RAILS_ENV=production

「xxxxxx」の部分に、プラグインの名称を設定します。

例えば、Parent issue filter pluginを削除する際は、

$ rake redmine:plugins:migrate  NAME=parent_issue_filter VERSION=0 RAILS_ENV=production

というコマンドを実行します。

ちなみに、上記コマンドは「Rakefile」が存在する場所で実行する必要があります。
（「Rakefile」はRedmineのHomeディレクトリに存在します。）
「Rakefile」が無いと、以下のようなエラーメッセージが出ます。

rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)

また、コマンドを実行した後、

$ rm -rf [Redmine HOME]/plugins/parent_issue_filter

というコマンドを実行する事で。実体のファイルも削除する必要があります。
※[Redmine HOME]は適宜環境によって書き換えて下さい。

３）バージョンアップ前準備（Rubyのバージョンアップ）

Redmine 3.3 から、Ruby 2.3 に対応しているようなので、Rubyもバージョンアップしようと思います。
（EC2でインスタンス作成時、Amazon Linuxの場合、Ruby2.0がインストール済みとなってるので、
「rbenv」を使用して、バージョン2.3をインストールします）

rbenvは、GitHubからクローンする必要があるので、gitがインストールされていない場合はインストールします。

$ sudo yum install git

※弊社は、同一インスタンスでGitのリポジトリも管理しているので、gitはインストールしてある状態でした。
・・・この同一インスタンス内で色々なシステムを導入しているのが、今回のバージョンアップになかなか踏み切れなかった要因です。

gitがインストール済みかどうかは、下記のコマンドで確認できます。

$ yum list installed | grep 'git'

さて、rbenvのインストールのやり方は、
https://github.com/rbenv/rbenv#installation
の通りに実行していくだけです。
（homeディレクトリで実施するのが良さそうです）

Githubからチェックアウト。

$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv

環境設定ファイルにパスを追加。

$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile

initコマンドを呼び出すように設定します。

$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile

パスの変更を有効する為に、一度ターミナルの接続を切り、再接続します。

動作確認は以下のコマンドで行います。

$ rbenv -v

rbenvは、rubyのバージョン切り替えツールなので、
次はrubyのインストールを簡単にするプラグイン（ruby-build）をインストールします。

$ git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

以下のコマンドで、インストール可能なバージョンを確認します。

$ rbenv install -l

現時点（2016/11/12）最新安定版のバージョン 2.3.1 をインストールします。

$ rbenv install 2.3.1

ここでエラーが出ました。

Downloading ruby-2.3.1.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.1.tar.bz2
Installing ruby-2.3.1...

BUILD FAILED (Amazon Linux AMI 2016.09 using ruby-build 2016xxxx-xx-xxxxxxxxx)

Inspect or clean up the working tree at /tmp/ruby-build.2016xxxxxxxx.xxxxx
Results logged to /tmp/ruby-build.2016xxxxxxxx.xxxxx.log

Last 10 log lines:
installing rdoc:              /home/officekoma/.rbenv/versions/2.3.1/share/ri/2.3.0/system
installing capi-docs:         /home/officekoma/.rbenv/versions/2.3.1/share/doc/ruby
The Ruby readline extension was not compiled.
ERROR: Ruby install aborted due to missing extensions
Try running `yum install -y readline-devel` to fetch missing dependencies.

Configure options used:
  --prefix=/home/officekoma/.rbenv/versions/2.3.1
  LDFLAGS=-L/home/officekoma/.rbenv/versions/2.3.1/lib 
  CPPFLAGS=-I/home/officekoma/.rbenv/versions/2.3.1/include

ここはエラーメッセージの通り、

$ sudo yum install -y readline-devel

を実行し、その後無事にインストール成功しました。

インストールに成功したところで、バージョンを切り替えます。
まずは、現在の選択されているRubyのバージョンを確認します。

$ rbenv versions
* system (set by /home/officekoma/.rbenv/version)
  2.3.1

systemが選択されています・・・バージョンが分からない、という事で、

$ ruby -v
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]

現在選択されているのは「2.0」だということが分かりました。

さて、バージョンを変えてみます。

$ rbenv global 2.3.1

再度、現在の選択されているRubyのバージョンを確認します。

$ rbenv versions
  system
* 2.3.1 (set by /home/ofkomamanage/.rbenv/version)

$ ruby -v
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux]

現在の選択バージョンが「2.3.1」になりました。

ようやく、Redmineのアップグレードですが・・・長くなってきたので、次回に持ち越します。

次回：Redmineのバージョンアップ 2.5 → 3.3 その２

オフィス狛 技術部です。

IoT関連のプロジェクトでは、多く使われている Raspberry Pi 。
弊社でも、BLEソリューションや、その他実証実験などで、使っています。

Raspberry Pi 3 になって、性能も良くなっているのですが、
たまに不安定になって、フリーズしてしまう事があります。

メモリ不足になっているとか、要因は色々あるのですが、
常時稼働すべき用途の場合、フリーズしてしまうのは困ってしまいます。

と言う事で、ウォッチドッグタイマーの出番です。

ウォッチドッグタイマーとは

メインのプログラムがハングアップなどの不正な状態に陥ってしまい、規則的なウォッチドッグ操作（「犬をなでる」とも呼ばれる「サービスパルス」の書き込み）が行なわれなかった（タイムアウト）場合に、例外処理が実行される。例外処理は、ハングアップしたシステムを正常動作に戻すことを目的としてシステムをリセットする場合が多いが、電源切断によりシステムを強制停止させるものや電源を切断した後に再投入するものもある。
タイマーはソフトウェアではなく、ハードウェアを用いる。これは、ソフトウェアで実装してしまうと、ソフトウェア自体が故障した際にタイマーの役割を果たさなくなったり、リセット信号を発生できなくなってしまう恐れがあるためである。
障害を引き起こした問題のデバッグに役立つ情報などを媒体に保存する機能を持つ場合、ウォッチドッグタイマーはより複雑なこともある。たとえば、最初のウォッチドッグタイマーのタイムアウトによって開始された情報の保存処理がある時間内に完了しなかった場合、情報が保存されていてもいなくても、2番目のシンプルなウォッチドッグタイマーがシステムを確実にリセットさせる。ウォッチドッグタイマーが最も多く使われているのは組み込みシステムで、マイクロコントローラに内蔵されていることも多い。
「ウォッチドッグタイマー」『フリー百科事典　ウィキペディア日本語版』より。
2016年3月21日 (月) 08:29‎ UTC
URL: https://ja.wikipedia.org/wiki/ウォッチドッグタイマー

ウォッチドッグタイマーのインストールと設定

以降のコマンドは、root権限で実行してください。
（「su」でrootになるか、「sudo」をコマンドの頭に付ける）
また、OSは「Raspbian Jessie Kernel version:4.4」を想定しています。

以下のコマンドで、watchdogをインストールします。

$ apt-get install watchdog

サービスの登録を行う為に、「watchdog.service」ファイルを編集します。

$ vi /lib/systemd/system/watchdog.service

※「[Install]」の下に下記を追加して、保存後、ファイルを閉じます。
WantedBy=multi-user.target

自動起動設定を行います。

$ update-rc.d watchdog enable

カーネルモジュールをロードします。

$ modprobe bcm2708_wdog

watchdog.conf の編集を行います。

$ vi /etc/watchdog.conf

※以下の部分のコメントを外し、保存後、ファイルを閉じます。
#watchdog-device = /dev/watchdog

/etc/default/watchdog の編集を行います。

$ vi /etc/default/watchdog

※watchdog_module="none"の「none」を「bcm2708_wdog」に変え、保存後、ファイルを閉じます。

再起動します。

$ reboot

再起動後、以下のコマンドを実行し、自動で再起動すればOKです。

$ :(){ :|:& };:

今回、下記サイトを参考にしたのですが、ちょっと情報が古かったり、やり方がサイトによって微妙に異なっていたりしたので、
Raspberry Pi 3 の「Raspbian Jessie Kernel version:4.4」で、問題なく動作した方法を記載しています。

【参考】
http://ivis-mynikki.blogspot.jp/2015/03/raspberry-pi.html
http://ecoday.jp/881/raspberry-pi-2-にウォッチドッグタイマーを導入する%E3%80%82/
http://machiawasepoint.com/raspberry-pi-jessieにwatchdogをインストール/