lxc exec 介绍
LXD lxc
![](/data/attachment/album/201708/06/092553aufwyyrjurjyo48c.jpg)


最近，我对 `lxc exec` 进行了几个改进。如果你不知道它的话我介绍一下，`lxc exec` 是 [LXD](https://github.com/lxc/lxd) 的客户端工具，使用 [LXD](https://github.com/lxc/lxd) [客户端 api](https://github.com/lxc/lxd/blob/master/client.go) 与 LXD 守护程序通信，并执行用户想要执行的各种程序，以下是你可以使用的一个例子：


![](/data/attachment/album/201708/06/092753p9d6m8x6zpzzmw91.jpg)


我们的主要目标之一就是使 `lxc exec` 与 `ssh` 类似，因为它是交互式或非交互式远程运行命令的标准。这使得 把 `lxc exec` 做得很好变得有点棘手。


### 1、 处理后台任务


一个长期存在的问题当然是如何正确处理后台任务。这是一个关于 [LXD](https://github.com/lxc/lxd) 2.7 实例的问题的例子：


![](/data/attachment/album/201708/06/092828hjujj20x2zby8xm3.jpg)


你可以看到，在后台执行任务将导致 `lxc exec` 无法退出。许多命令可以触发此问题：



```
chb@conventiont|~
> lxc exec zest1 bash
root@zest1:~# yes &
y
y
y
.
.
.

```

现在没有什么能救你了。`yes` 将会永远直接写入`stdout`。


问题的根源在于 `stdout` 是一直打开着的，但这是必要的，因为它用以确保用户所启动的进程写入的任何数据实际上都是通过我们建立的 websocket 连接读取并发回的。


假如你想这样，运行一个 shell 会话，然后在后台运行一个进程，并马上退出 shell。对不起，它并不能如预期那样。


第一种并且原始的方法是一旦你检测到前台程序（例如 shell）已经退出就直接关闭 `stdout`。但这不像想得那么好，当你运行快速执行程序时，这个问题会变得明显，比如：



```
lxc exec -- ls -al /usr/lib

```

这里 `lxc exec` 进程（和相关的 `forkexec` 进程。但现在不要考虑它，只要记住 `Go` + `setns()` 不相往来就行了……）会在 `stdout` 中所有的*缓冲*数据被读取之前退出。这种情况下将会导致截断输出，没有人想要这样。在尝试使用几个方法来解决问题之后，包括禁用 pty 缓冲（我告诉你，这不太漂亮，也没有如预期工作。）和其他奇怪的思路，我设法通过几个 `poll()` “技巧”（在某种意义上说一个“技巧”）解决了这个问题。现在你终于可以运行后台任务，并且可以完全退出了。如图：


![](/data/attachment/album/201708/06/092902v3g6ltlhkkm8mgkh.jpg)


### 2、 报告由信号引起的退出码


`ssh` 是一个很棒的工具。但有一件事，我一直以来不喜欢当 ssh 运行的命令接收到一个信号时， `ssh` 总是会报告 `-1`，也就是退出码 `255`。当你想要了解导致程序终止的信号时，这很烦人。这就是为什么我最近实施标准 shell 所使用的惯例 `128 + n` 来报告任何由信号导致的退出，其中 `n` 被定义为导致执行程序退出的信号量。例如，在 `SIGKILL` 信号上，你会看到 `128 + SIGKILL = 137`（计算其他致命信号的退出码作为读者的练习）。所以你可以这么做：



```
chb@conventiont|~
> lxc exec zest1 sleep 100

```

现在，将 `SIGKILL` 发送到执行程序（不是 `lxc exec`本身，因为 `SIGKILL` 不可转发）。



```
kill -KILL $(pidof sleep 100)

```

最后检查你程序的退出码：



```
chb@conventiont|~
> echo $?
137

```

瞧。这显然只有当 a) 退出码没有超过 `8` 位计算壁垒，b）当执行程序不使用 `137` 来表示成功（这可真……有趣？！）。这两个论点似乎对我来说都不太有说服力。前者因为致命信号量不*应该*超过这个范围。后者因为（i）这是用户问题，（ii）这些退出代码实际上是保留的（我是*这样认为*。），（iii）你在本地或其他上面运行程序时会遇到同样的问题。


我看到的主要优点是这能够回报执行程序细粒度的退出状态。注意，我们不会报告*所有*被信号杀死的程序实例。比如说，当你的程序能够处理 `SIGTERM` 并且完全退出时，[LXD](https://github.com/lxc/lxd) 没有简单的方法来检测到这个情况并报告说这个程序被信号杀死了。你只会简单地收到退出码 `0`。


### 3、 转发信号


这可能不太有趣（或者也许不是，谁知道呢），但我发现它非常有用。正如你在 `SIGKILL` 案例中看到的那样，我明确地指出，必须将 `SIGKILL` 发送到执行程序，而不是 `lxc exec`命令本身。这是因为 `SIGKILL` 在程序中无法处理。程序可以做的唯一的事情就是去死，像现在这样……像这个例子……马上（你明白了了吧……）。但是程序可以处理很多其他信号 `SIGTERM`、`SIGHUP'，当然也可以处理`SIGUSR1`和`SIGUSR2`。因此，当你发送可以被`lxc exec` 处理而不是被执行程序处理的信号时，较新版本的 [LXD](https://github.com/lxc/lxd) 会将信号转发到执行进程。这在脚本中非常方便。


无论如何，我希望你觉得这篇小小的 `lxc exec` 文章/胡言乱语有用。享受 [LXD](https://github.com/lxc/lxd) 吧，这是与一只疯狂的美丽的野兽玩耍。请试试在线实验：<https://linuxcontainers.org/lxd/try-it/>，对于开发人员看看这里：<https://github.com/lxc/lxd> 并给我们补丁。


我们不要求签署任何 CLA，我们遵循内核风格，只要其中有 “Signed-off-by” 这行就好。




---


via: <https://cbrauner.wordpress.com/2017/01/20/lxc-exec-vs-ssh/>


作者：[brauner](https://cbrauner.wordpress.com) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
Recently, I’ve implemented several improvements for `lxc exec`

. In case you didn’t know, `lxc exec`

is [LXD](https://github.com/lxc/lxd)‘s client tool that uses the [LXD](https://github.com/lxc/lxd) [client api](https://github.com/lxc/lxd/blob/master/client.go) to talk to the LXD daemon and execute any program the user might want. Here is a small example of what you can do with it:

One of our main goals is to make `lxc exec`

feel as similar to `ssh`

as possible since this is the standard of running commands interactively or non-interactively remotely. Making `lxc exec`

behave nicely was tricky.

## 1. Handling background tasks

A long-standing problem was certainly how to correctly handle background tasks. Here’s an asciinema illustration of the problem with a pre [LXD](https://github.com/lxc/lxd) 2.7 instance:

What you can see there is that putting a task in the background will lead to `lxc exec`

not being able to exit. A lot of sequences of commands can trigger this problem:

chb@conventiont|~ > lxc exec zest1 bash root@zest1:~# yes & y y y . . .

Nothing would save you now. `yes`

will simply write to `stdout`

till the end of time as quickly as it can…

The root of the problem lies with `stdout`

being kept open which is necessary to ensure that any data written by the process the user has started is actually read and sent back over the websocket connection we established.

As you can imagine this becomes a major annoyance when you e.g. run a shell session in which you want to run a process in the background and then quickly want to exit. Sorry, you are out of luck. Well, you were.

The first, and naive approach is obviously to simply close `stdout`

as soon as you detect that the foreground program (e.g. the shell) has exited. Not quite as good as an idea as one might think… The problem becomes obvious when you then run quickly executing programs like:

lxc exec -- ls -al /usr/lib

where the `lxc exec`

process (and the associated `forkexec`

process (Don’t worry about it now. Just remember that `Go`

+ `setns()`

are not on speaking terms…)) exits before all *buffered* data in `stdout`

was read. In this case you will cause truncated output and no one wants that. After a few approaches to the problem that involved, disabling pty buffering (Wasn’t pretty I tell you that and also didn’t work predictably.) and other weird ideas I managed to solve this by employing a few `poll()`

“tricks” (In some sense of the word “trick”.). Now you can finally run background tasks and cleanly exit. To wit:


## 2. Reporting exit codes caused by signals

`ssh`

is a wonderful tool. One thing however, I never really liked was the fact that when the command that was run by ssh received a signal `ssh`

would always report `-1`

aka exit code `255`

. This is annoying when you’d like to have information about what signal caused the program to terminate. This is why I recently implemented the standard shell convention of reporting any signal-caused exits using the standard convention `128 + n`

where `n`

is defined as the signal number that caused the executing program to exit. For example, on `SIGKILL`

you would see `128 + SIGKILL = 137`

(Calculating the exit codes for other deadly signals is left as an exercise to the reader.). So you can do:

chb@conventiont|~ > lxc exec zest1 sleep 100

Now, send `SIGKILL`

to the executing program (Not to `lxc exec`

itself, as `SIGKILL`

is not forwardable.):

kill -KILL $(pidof sleep 100)

and finally retrieve the exit code for your program:

chb@conventiont|~ > echo $? 137

Voila. This obviously only works nicely when a) the exit code doesn’t breach the `8`

-bit wall-of-computing and b) when the executing program doesn’t use `137`

to indicate success (Which would be… interesting(?).). Both arguments don’t seem too convincing to me. The former because most deadly signals *should* not breach the range. The latter because (i) that’s the users problem, (ii) these exit codes are actually reserved (I *think*.), (iii) you’d have the same problem running the program locally or otherwise.

The main advantage I see in this is the ability to report back fine-grained exit statuses for executing programs. Note, by no means can we report back *all* instances where the executing program was killed by a signal, e.g. when your program handles `SIGTERM`

and exits cleanly there’s no easy way for [LXD](https://github.com/lxc/lxd) to detect this and report back that this program was killed by signal. You will simply receive success aka exit code `0`

.

## 3. Forwarding signals

This is probably the least interesting (or maybe it isn’t, no idea) but I found it quite useful. As you saw in the `SIGKILL`

case before, I was explicit in pointing out that one must send `SIGKILL`

to the executing program not to the `lxc exec`

command itself. This is due to the fact that `SIGKILL`

cannot be handled in a program. The only thing the program can do is die… like right now… this instance… sofort… (You get the idea…). But a lot of other signals `SIGTERM`

, `SIGHUP`

, and of course `SIGUSR1`

and `SIGUSR2`

can be handled. So when you send signals that can be handled to `lxc exec`

instead of the executing program, newer versions of [LXD](https://github.com/lxc/lxd) will forward the signal to the executing process. This is pretty convenient in scripts and so on.

In any case, I hope you found this little `lxc exec`

post/rant useful. Enjoy [LXD](https://github.com/lxc/lxd) it’s a crazy beautiful beast to play with. Give it a try online [https://linuxcontainers.org/lxd/try-it/](https://linuxcontainers.org/lxd/try-it/) and for all you developers out there: Checkout [https://github.com/lxc/lxd](https://github.com/lxc/lxd) and send us patches. 🙂 We don’t require any `CLA`

to be signed, we simply follow the kernel style of requiring a `Signed-off-by`

line. 🙂