<replaceable>/sys</replaceable> filesystems contain information
about some quantities that are affected by namespaces, such as
the directories named after process ids in
- <replaceable>/proc</replaceable> or the network interface infromation
+ <replaceable>/proc</replaceable> or the network interface information
in <replaceable>/sys/class/net</replaceable>. The namespace of the
process mounting the pseudo-filesystems determines what information
is shown, <emphasis>not</emphasis> the namespace of the process
<!--
Specify the tty number to connect to or 0 for the console. If not
specified the next available tty number will be automatically
- choosen by the container.
+ chosen by the container.
-->
接続する tty の番号か,コンソールに接続するために 0 を指定します.指定しない場合は,次に利用可能な tty 番号を自動的にコンテナが選択します.
</para>
<para>
<!--
<command>lxc-create</command> creates a system object where is
- stored the configuration informations and where can be stored
+ stored the configuration information and where can be stored
user information. The identifier <replaceable>name</replaceable>
is used to specify the container to be used with the different
lxc commands.
<!--
The object is the definition of the different resources an
application can use or can see. The more the configuration file
- contains informations, the more the container is isolated and
+ contains information, the more the container is isolated and
the more the application is jailed.
-->
オブジェクトは,アプリケーションが使用したり,参照したりする様々なリソースの定義です.設定ファイルがより多くの情報を持つほど,コンテナやアプリケーションはより隔離されたものになります.
process, <command>lxc-init</command>.
This lxc-init after launching the specified command,
will wait for its end and all other reparented processes.
- (that allows to support daemons in the container).
+ (to support daemons in the container).
In other words, in the
container, <command>lxc-init</command> has the pid 1 and the
first process of the application has the pid 2.
<title><!-- Architecture -->アーキテクチャ</title>
<para>
<!--
- Allows to set the architecture for the container. For example,
+ Allows one to set the architecture for the container. For example,
set a 32bits architecture for a container running 32bits
binaries on a 64bits host. That fixes the container scripts
which rely on the architecture to do some work like
<title><!-- Stop signal -->停止時のシグナル</title>
<para>
<!--
- Allows to specify signal name or number, sent by lxc-stop to
+ Allows one to specify signal name or number, sent by lxc-stop to
shutdown the container. Different init systems could use
different signals to perform clean shutdown sequence. Option
allows signal to be specified in kill(1) fashion, e.g.
process, <command>lxc-init</command>.
This lxc-init after launching the specified command,
will wait for its end and all other reparented processes.
- (that allows to support daemons in the container).
+ (to support daemons in the container).
In other words, in the
container, <command>lxc-init</command> has the pid 1 and the
first process of the application has the pid 2.
When there are a lot of containers, it is hard to follow
what has been created or destroyed, what is running or what are
the pids running into a specific container. For this reason, the
- following commands may be usefull:
+ following commands may be useful:
<programlisting>
lxc-ls
lxc-ps --name foo
<para>
<!--
- <command>lxc-info</command> gives informations for a specific
+ <command>lxc-info</command> gives information for a specific
container, at present time, only the state of the container is
displayed.
-->
<para>
<!--
- The following command will display the socket informations for
+ The following command will display the socket information for
the container 'foo'.
<programlisting>
lxc-netstat -n foo -tano
<replaceable>/sys</replaceable> filesystems contain information
about some quantities that are affected by namespaces, such as
the directories named after process ids in
- <replaceable>/proc</replaceable> or the network interface infromation
+ <replaceable>/proc</replaceable> or the network interface information
in <replaceable>/sys/class/net</replaceable>. The namespace of the
process mounting the pseudo-filesystems determines what information
is shown, <emphasis>not</emphasis> the namespace of the process
<para>
Specify the tty number to connect to or 0 for the console. If not
specified the next available tty number will be automatically
- choosen by the container.
+ chosen by the container.
</para>
</listitem>
</varlistentry>
<para>
<command>lxc-create</command> creates a system object where is
- stored the configuration informations and where can be stored
+ stored the configuration information and where can be stored
user information. The identifier <replaceable>name</replaceable>
is used to specify the container to be used with the different
lxc commands.
<para>
The object is the definition of the different resources an
application can use or can see. The more the configuration file
- contains informations, the more the container is isolated and
+ contains information, the more the container is isolated and
the more the application is jailed.
</para>
process, <command>lxc-init</command>.
This lxc-init after launching the specified command,
will wait for its end and all other reparented processes.
- (that allows to support daemons in the container).
+ (to support daemons in the container).
In other words, in the
container, <command>lxc-init</command> has the pid 1 and the
first process of the application has the pid 2.
<refsect2>
<title>Architecture</title>
<para>
- Allows to set the architecture for the container. For example,
+ Allows one to set the architecture for the container. For example,
set a 32bits architecture for a container running 32bits
binaries on a 64bits host. This fixes the container scripts
which rely on the architecture to do some work like
<refsect2>
<title>Stop signal</title>
<para>
- Allows to specify signal name or number, sent by lxc-stop to
+ Allows one to specify signal name or number, sent by lxc-stop to
shutdown the container. Different init systems could use
different signals to perform clean shutdown sequence. Option
allows signal to be specified in kill(1) fashion, e.g.
process, <command>lxc-init</command>.
This lxc-init after launching the specified command,
will wait for its end and all other reparented processes.
- (that allows to support daemons in the container).
+ (to support daemons in the container).
In other words, in the
container, <command>lxc-init</command> has the pid 1 and the
first process of the application has the pid 2.
<para>When there are a lot of containers, it is hard to follow
what has been created or destroyed, what is running or what are
the pids running into a specific container. For this reason, the
- following commands may be usefull:
+ following commands may be useful:
<programlisting>
lxc-ls
lxc-ps --name foo
</para>
<para>
- <command>lxc-info</command> gives informations for a specific
+ <command>lxc-info</command> gives information for a specific
container, at present time, only the state of the container is
displayed.
</para>
</para>
<para>
- The following command will display the socket informations for
+ The following command will display the socket information for
the container 'foo'.
<programlisting>
lxc-netstat -n foo -tano
};
if (req->cmd < 0 || req->cmd >= LXC_CMD_MAX) {
- ERROR("bad cmd %d recieved", req->cmd);
+ ERROR("bad cmd %d received", req->cmd);
return -1;
}
return cb[req->cmd](fd, req, handler);