<CHAPTER ID="Problems">
<!-- <TITLE>Common Problems</TITLE> -->
<TITLE>共通の問題</TITLE>
<!-- <sect1><title>Introduction</title> -->
<sect1><title>はじめに</title>
<!--
<para>Although most of the issues in this chapter could be a part of the FAQ. There where the FAQ will give a 
short <quote>how to solve</quote> answer,  we have taken a closer look at them 
and explained why they are problems and how to solve them.
-->
<para>この章にある課題の大部分は、FAQ としても成り立ちます。FAQ は手短に
<quote>どのように解決するか</quote>に対する回答です。しかしここではもっと
細に入り、なぜ問題が生じるのかを説明した上で、それをどのように解決するの
かを説明します。
</para>
</sect1>
<SECT1>
<!-- <TITLE>My processes won't migrate</TITLE> -->
<TITLE>プロセスがマイグレートしない</TITLE>
<PARA>
<!--
<emphasis>Help  process XYZ doesn't migrate.  </emphasis>
-->
<emphasis>助けてください。プロセス XYZ がマイグレートしません</emphasis>

<!--
Moshe Bar explains below why some processes migrate and why some don't.
But before that you can always look in /proc/$pid/, there often is a 
<emphasis>cantmove</emphasis> file which will tell you why a certain 
process can't migrate.
-->
下記で Moshe Bar 氏はなぜプロセスにマイグレートするもの、しないものが
あるのかを説明しています。いつものように /proc/$pid/ を見る前に、
<emphasis>cantmove</emphasis>を見てください。該当プロセスがなぜマイグレート
できないのかわかるでしょう。
</para>
<para>
<!--
Processes can also be locked.  
You can check if a process is locked with:
-->
プロセスをロックすることもできますが、プロセスがロックされていないか
どうかもチェックできます。
<programlisting>
cat /proc/$PID/lock</programlisting>
<!--
where $PID is the processid of the process in question.
-->
＄PID は問題のプロセスのプロセス ID です。

</para>
<para>
<!--
Now  listen to what  Moshe himself has to say about this 
topic.
-->
では、Moshe 氏自身がこの件について述べたことを挙げます。

</para>
<!--
<para>Often people have the same kernel but on a different 
distribution, say a mixed environment of RedHat and Debian ,rc 
scripts from different distros tend to start openmosix 
differently.    Some implementations completely modify 
/etc/inittab to start all daemons (and their children) with 
<programlisting>mosrun -h</programlisting>. So that they won't migrate.  
Therefore all these processes have a 1 in 
/proc/pid/lock  when you start. You can force them to migrate 
by writing a 0 to this file .</para> <para>
-->
<para>
よくあるのは、同じカーネルを使ってはいるが、RedHat と Debian が混在している
といったようなディストリビューションに相違があるケースです。ディストリ
ビューションが異なると、rc スクリプトが異なるやり方で openMosix を起動する
傾向にあります。
ある実装では /etc/inittab をすっかり書き換えてデーモンすべて(とその子供も)を 
<programlisting>mosrun -h</programlisting> で起動しています。
そのように起動するとマイグレートしません。
したがってプロセスを動かすと、これらのプロセスすべては /proc/pid/lock が 1 
になります。強制的にマイグレートさせるためには、このファイルに 0 を記述
します。
</para> <para>

<!--
Ok, this simple program should always migrate if launched more times than
number of local CPUs. So for a 2-way SMP system, starting this program 3
times will start migration if the other nodes in the cluster have at least
the same speed like the local ones:
-->
それでは、下記の単純なプログラムをローカルの CPU 数より多く起動して、常に
マイグレートさせてみましょう。2-way SMP システムでは、このプログラムを 3 回
起動し、クラスタ内にあるノードがローカルのシステムと似たような速度を持って
いれば、マイグレートします。

<programlisting>
int main() {
    unsigned int i;
    while (1) {
        i++;
    }
    return 0;
}
</programlisting>

<!--
On a Pentium 800Mhz CPU it takes quite a while to overflow.
-->
Pentium 800Mhz という CPU では、オーバーフローするまでに多少時間がかかります。

</para>
<PAra>



<!--
This sample program with content like this will never migrate:
-->
下記のような内容を持つサンプルプログラムは、決してマイグレートしません。

<programlisting>
<![CDATA[
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/shm.h>

...

key_t key; /* key to be passed to shmget() */
int shmflg; /* shmflg to be passed to shmget() */
int shmid; /* return value from shmget() */
int size; /* size to be passed to shmget() */

...

key = ...
size = ...
shmflg) = ...

if ((shmid = shmget (key, size, shmflg)) == -1) {
   perror("shmget: shmget failed"); exit(1); } else {
   (void) fprintf(stderr, "shmget: shmget returned %d\n", shmid);
   exit(0);
  }
...
]]>
</programlisting>

</PARA>
<PARa>

<!--
Program using pipes like this do migrate nicely:
-->
下記のようなパイプを使ったプログラムは、うまくマイグレートします。


<programlisting>

int pdes[2];

pipe(pdes);
if ( fork() == 0 )
  { /* child */
                                 close(pdes[1]); /* not required */
                                 read( pdes[0]); /* read from parent */
                                 .....
                 }
else
                 { close(pdes[0]); /* not required */
                                 write( pdes[1]); /* write to child */
                                 .....
                 }
</programlisting>

<!--
<emphasis>MODIFIED</emphasis>
Programs using pthreads since version 2.4.17 don't migrate, however they 
don't segfault anymore.
-->
pthread を使うように<emphasis>修正された</emphasis>プログラムは、バージョン 
2.4.17 からマイグレートはしませんが、segmentation fault はしなくなりました。


<programlisting>
<![CDATA[
//
// Very simple program demonstrating the use of threads.
//
// Command-line argument is P (number of threads).
//
// Each thread writes "hello" message to standard output, with
//   no attempt to synchronize.  Output will likely be garbled.
//
#include <iostream>
#include <cstdlib>              // has exit(), etc.
#include <unistd.h>             // has usleep()
#include <pthread.h>            // has pthread_ routines

// declaration for function to be executed by each thread
void * printHello(void * threadArg);

// ---- Main program -------------------------------------------------

int main(int argc, char* argv[]) {

  if (argc < 2) {
    cerr << "Usage:  " << argv[0] << " numThreads\n";
    exit(EXIT_FAILURE);
  }
  int P = atoi(argv[1]);

  // Set up IDs for threads (need a separate variable for each
  //   since they're shared among threads).
  int * threadIDs = new int[P];
  for (int i = 0; i < P; ++i)
    threadIDs[i] = i;

  // Start P new threads, each with different ID.
  pthread_t * threads = new pthread_t[P];
  for (int i = 0; i < P; ++i)
    pthread_create(&threads[i], NULL, printHello,
                   (void *) &threadIDs[i]);

  // Wait for all threads to complete.
  for (int i = 0; i < P; ++i)
    pthread_join(threads[i], NULL);

  // Clean up and exit.
  delete [] threadIDs;
  delete [] threads;
  cout << "That's all, folks!\n";
  return EXIT_SUCCESS;
}

// ---- Code to be executed by each thread ---------------------------

// pre:  *threadArg is an integer "thread ID".
// post:  "hello" message printed to standard output.
//        return value is null pointer.
void * printHello(void * threadArg) {
  int * myID = (int *) threadArg;
  cout << "hello, world, ";
  // pointless pause, included to make the effects of
  //   synchronization (or lack thereof) more obvious
  usleep(10);
  cout << "from thread " << *myID << endl;
  pthread_exit((void* ) NULL);
}
]]>


</programlisting>



<!--
Programs using all kinds of file descriptors, including sockets do migrate
(sockets are not migrated with the process however, files are migrated if
using oMFS/DFSA)
-->
プログラムがソケットを含む色々なファイルディスクリプタを使うと、マイグレート
します(プロセスとともにソケットはマイグレートしませんが、oMFS や DFSA を使用
していればファイルはマイグレートされます)。
</PARA>
<PARA>

<!--
(all above code is by Moshe  as Moshe Bar or by Moshe as CTO of Qlusters, Inc.)
-->
(上記のコードは Moshe 氏によるものです。Moshe Bar 氏個人によるもの、もしくは 
Qlusters, Inc. の CTO としての Moshe 氏のどちらかの立場です)。

</PARA>

<!--
<PARA>Please also refer to the man pages of openMosix , they also give an 
adequate explanation why processes don't migrate.
-->
<PARA>openMosix の man も参照してください。プロセスがどうしてマイグレート
しないかについて、それなりに説明してあります。

</PARA>
<PARA>
<!--
If for some reason your processes stay locked while they shouldn't. You 
can try to allow locked processes to migrate by simply putting
-->
何らかの理由で、意図せずにプロセスがロックしたままになってしまった場合、
ロックされたプロセスをマイグレートするには、下記の記述を

<programlisting>
# tell shells to allow subprocs to migrate to other nodes
echo 0 > /proc/self/lock
</programlisting>
<!--
into
<quote>/etc/profile
</quote>
-->
<quote>/etc/profile
</quote>
に単に追記するだけです。
<!--
Warning : this fix will allow <emphasis>all</emphasis> process to migrate 
not just the ones you want. To only allow specific process to migrate 
use 'mosrun  -l' to unlock only the desired process.
-->
注意：こうすると自分が望んだものだけでなく、<emphasis>すべての</emphasis>
プロセスがマイグレート可能になります。特定のプロセスだけをマイグレート
させたいなら「mosrun  -l」を使ってマイグレートさせたいプロセスだけをさせて
ください。

</PARA></SECT1>



<!-- 原文でコメントアウトしてあるので訳出しません。 -->
<!-- 
<SECT1>
<TITLE>setpe reports</TITLE>
<PARA>
</PARA>
</SECT1>
-->
<SECT1>
<!-- <TITLE>I don't see all my nodes</TITLE> -->
<TITLE>ノードが何も見えません</TITLE>
<PARA>

<!--
First of all , are you using the same kernel version on each machine ? 
The 'same-kernel' refers to the version. You can build different kernel 
images of the same source version to meet the hardware/software needs of a 
given node.
However you wil need toe make sure that when you install openMosix 
on your cluster, all your machines should have the openmosix-x.x.x-y 
kernel installed, in contrast to having one machine running 
openmosix-x.x.z-x, another running openmosix-x.x.x-y, another running 
openmosix x.x.x-z, and so on and so forth
-->
まず各マシンで同じバージョンのカーネルを使っているか見てください。
「同じカーネル」とはバージョンを意味しています。同じソースバージョンから
ハードウェアやソフトウェアの都合によって、各ノードで別々のカーネルを構築
しても大丈夫です。
しかしクラスタに openMosix をインストールした時には、マシンにはすべて 
openmosix-x.x.x-y カーネルが入っていなければいけません。openmosix-x.x.z-x が
あったり、openmosix-x.x.x-y があったり、openmosix x.x.x-z があったり等々では
いけません。

</para>
<para>

<!--
When you run mosmon, press t to see the total of machines running. Does 
it warn you that mosix is not running?
-->
mosmon を動かして t を押すと、稼動中のマシンすべてが見られます。mosmon が 
mosix が動いていないと警告しますか。

</para>
<PARA>

<!--
If yes, then make sure your machine's ip is included in /etc/mosix.map 
(don't use 127.0.0.1 - if your machine's ip is such, then you probably 
have problems with your dhcp server/nameserver). If it does not tell you 
that mosix is not running, see what machines show up. Do you see only your 
machine?
-->
警告するなら、まずマシンの IP アドレスが /etc/mosix.map にあるか確認して
ください(127.0.0.1 は使わないでください。使っていたなら、恐らく DHCP 
関連で問題があります)。mosix が停止していると警告しないなら、どのマシンが
見えているかを見てください。自分のマシンしか見えていませんか。

</para>
<para>

<!--
If yes, then your machine is most likely running a firewall and is not 
letting openmosix through.
-->
自分のマシンしか見えないなら、自分のマシンでファイアーウォールが動いている
可能性が高くなります。ファイアーウォールが openMosix を遮っています。
</para>
<para>

<!--
If not, then the problem is most likely with the machine that doesn't show 
up.
-->
他のマシンも見えるなら、見えないマシンの問題である可能性が高くなります。

<!--
Also: Do you have two nic cards on a node? then you have to edit the 
/etc/hosts file to have a line that has the following format 
-->
もう一つ。ノードにネットワークカードが 2 枚ありませんか。そうなら 
/etc/hosts ファイルをいじって、下記の書式で行を追加してください。
<programlisting>
non-cluster_ip  cluster-hostname.cluster-domain cluster-hostname
</programlisting>

<!--
You 
might also 
need to set up a routing table, which is a whole different subject. 
-->
もしかすると経路テーブルを設定する必要があるかもしれませんが、また別の
課題です。
</para>
<para>
<!--
Maybe you used different kernel-parameters on each machine? Especially if 
you use the 'Support clusters with a complex network topology' option you 
should take care that you use the same value for the also appearing option 
'Maximum network-topology complexity support' on each machine.
-->
各マシンでカーネルパラメタを別々に設定していませんか。
特に「Support clusters with a complex network topology」オプションを使って
いる場合、似たようなオプションである「Maximum network-topology complexity 
support」を各マシンで同じ値にしてください。

 </PARA> 
</SECT1>

<SECT1>
<TITLE>
<!--
I often get errors: No such process
-->
よく「No such process」というエラーがでます。
</TITLE>

<PARA>
<!--
I often get the error <programlisting>bash: child setpgid (4061 to 4061): No such process</programlisting>
what does this mean ? 
-->
<programlisting>bash: child setpgid (4061 to 4061): No such process</programlisting>
というエラーがよく出ます。これはどういう意味でしょう。

</PARA>
<PARA>
<!--
The above line meas that the shell you were using 
has acutallly migrated
to another node ?
This printout from bash is caused by a bug in old version of
openmosix, but a fix has been commited.
(Muli Ben-Yehuda mulix@actcom.co.il)
-->
上記の行は、使っているシェルが実際に他のノードにマイグレートした
ことを意味するのでしょうか。
この bash からの出力は、openmosix の古いバージョンのバグによって
起こります。既に修正されてコミット済みです(Muli Ben-Yehuda 
mulix@actcom.co.il)。

</PARA>
</SECT1>

<SECT1><TITLE>DFSA ? MFS ? </TITLE>
<!--
<PARA>People often get confused about what exactly MFS and DFSA 
are.  
As discussed before in the howto MFS is the feature of openMosix 
that enables you access to remote filesystems as if those 
filesystems were locally mounted.  They are mostly mounted on 
/mfs . A common misunderstanding is that you need MFS in order 
to have openMosix working, this is not true, however it can make 
things easier.  
-->
<PARA>混乱がよく見られます。それは MFS と DFSA が正確には何なのかに
ついてです。
以前どのように MFS するのかで論じた通り、MFS とはリモートにあるファイル
システムをローカルにマウントしているようにみせる openMosix の機能を
指します。通常 /mfs でマウントされます。よくある誤解が openMosix を使う
のには MFS が必要だ、というものです。これは正しくありませんが、MFS が 
openMosix を使いやすくするのは事実です。

 </para> <para>
<!--
With DFSA enabled, system calls  will be executed on the remote 
node withouth migrating the process back to it's home node. This 
behaviour (direct filesystem access) causes processes migratiing 
to the data and not the other way around (which is common).  If 
DFSA is not enabled MfS is "just" a non-caching 
network-filesystem.
-->
DFSA が有効だと、プロセスをマイグレートしてホームノードに戻すこと無しに
システムコールがリモートにあるノードで実行されます。この動作(direct 
filesystem access)は、プロセスがデータをマイグレートしてその逆(これが普通)
はないということです。DFSA が MFS を有効にしていなければ、「ただの」
キャッシュ無しのネットワークファイルシステムになります。
</para>
<para>


<!--
Very generally speaking, if you don't have DFSA turned on, each and 
every I/O will go to the home node for execution. With DFSA turned on, 
if the file happens to be residing on the node where the process finds 
itself then the I/O will happen locally.
-->
大まかに言えば、DFSA を有効にしないと、I/O はすべてホームノードで実行され
ます。DFSA を有効にすると、ノードにプロセスもファイルも存在していれば、
そのノードで I/O がローカルに行われます。

</para> <para>

<!--
A very common error is that people mix kernels with DFSA enabled 
and disabled.  So one has to have a way to find out wether DFSA 
is actually enabled. This information can be obtained by typing
-->
ありがちな間違いは、カーネルで DFSA の有効・無効を混在させてしまう
ことです。そこで DFSA が実際に有効になっているのかを知る方法が必須
になります。この情報は次のように入力すればわかります。
<programlisting>
cat /proc/hpc/admin/version
</programlisting>

</PARA>
</SECT1>
<!-- <SECT1><TITLE>Python Troubles</TITLE> -->
<SECT1><TITLE>Python のトラブル</TITLE>
<PARA>
<!--
Some people have reported problems with Python, closer research showed 
that these problems were not with openMosix but rather with glibc 
issues, however it seemed that issues manifested themselves especially 
in openMosix.
-->
Python 関連のトラブルが報告されるケースもあります。よくよく調べてみると、
openMosix に問題があるわけではなく、glib に関連した問題でした。しかし
openMosix の問題であるかのごとく見えました。
</para><para>
<!--
One user solved the problem by removig /lib/i686/lib* on his machine and let 
the applications link dynamically against /lib/libpthread (and other)
However bugfixes in newer glibc versions combined with more recent openMosix 
version seem to have solved these problems.
-->
/lib/i686/lib* をマシンから削除し、アプリケーションを動的に /lib/libpthread 
他にリンクしないようにして解決したユーザもいます。
しかし新しい glib バージョンではバグが修正されていて、最近の openMosix では
この問題は解決したようです。
</PARA>
</sect1>
</CHAPTER>

