lxc exec: 독특한 매력을 탐험해보세요

소개	최근에 나는 lxc exec를 몇 가지 개선했습니다. 혹시 모르신다면 소개해드리죠. lxc exec는 LXD 클라이언트 API를 사용하여 LXD 데몬과 통신하고 사용자가 실행하려는 다양한 프로그램을 실행하는 예제입니다. 당신이 사용할 수 있는 것:

우리의 주요 목표 중 하나는 원격, 대화형 또는 비대화형으로 명령을 실행하기 위한 표준인 lxc exec를 ssh와 유사하게 만드는 것입니다. 이로 인해 lxc exec를 제대로 수행하는 것이 약간 까다로워졌습니다.

1. 백그라운드 작업 처리

오랜 문제는 물론 백그라운드 작업을 적절하게 처리하는 방법입니다. 다음은 LXD 2.7 인스턴스 문제의 예입니다.

백그라운드에서 작업을 실행하면 lxc exec가 종료되지 않는 것을 볼 수 있습니다. 많은 명령이 이 문제를 유발할 수 있습니다.

으아아아

이제 아무것도 당신을 구할 수 없습니다. yes는 항상 stdout에 직접 기록합니다.

문제의 근본 원인은 stdout이 항상 열려 있다는 것입니다. 그러나 이는 사용자가 시작한 프로세스에서 작성된 모든 데이터를 실제로 읽고 우리가 설정한 웹 소켓 연결을 통해 다시 전송하는 데 사용되기 때문에 필요합니다.

이 작업을 수행하려면 쉘 세션을 실행한 다음 백그라운드에서 프로세스를 실행하고 바로 쉘을 종료하세요. 죄송합니다. 예상대로 작동하지 않습니다.

첫 번째이자 기본적인 접근 방식은 포그라운드 프로그램(예: 셸)이 종료되었음을 감지한 후 간단히 stdout을 닫는 것입니다. 그러나 이것은 보이는 것만큼 좋지 않습니다. 다음과 같은 빠른 실행 프로그램을 실행할 때 이 문제는 명백해집니다. 으아아아

여기 lxc exec 프로세스(및 관련 forkexec 프로세스. 하지만 지금은 생각하지 마세요. Go + setns()는 상호 작용하지 않는다는 점만 기억하세요...)는 stdout의 모든 버퍼링된 데이터를 읽기 전에 종료됩니다. . 이 상황에서는 누구도 원하지 않는 잘린 출력이 발생합니다. pty 버퍼링 비활성화(예상대로 좋지도 않고 예상대로 작동하지 않음)와 기타 이상한 아이디어를 포함하여 문제를 해결하기 위해 여러 가지 방법을 시도한 후 몇 가지 poll() "트릭"( 어떤 의미에서 "트릭")은 이 문제를 해결합니다. 이제 마침내 백그라운드 작업을 실행하고 완전히 종료할 수 있습니다. 그림과 같이:

2. 신호로 인한 종료 코드 보고 ssh는 훌륭한 도구입니다. 그러나 제가 항상 싫어했던 점 중 하나는 ssh가 실행하는 명령이 신호를 수신할 때 ssh가 항상 종료 코드 255인 -1을 보고한다는 것입니다. 프로그램을 종료시키는 신호를 이해하고 싶을 때 이는 성가신 일입니다. 이것이 바로 제가 최근 128 + n 신호로 인한 종료를 보고하기 위해 표준 쉘에서 사용하는 규칙을 구현한 이유입니다. 여기서 n은 실행기를 종료시키는 세마포어로 정의됩니다. 예를 들어, SIGKILL 신호에서는 128 + SIGKILL = 137이 표시됩니다(독자의 연습을 위해 다른 치명적인 신호에 대한 종료 코드를 계산하십시오). 그러면 이렇게 할 수 있습니다:

으아아아

이제 SIGKILL을 실행자에게 보냅니다(SIGKILL은 전달할 수 없으므로 lxc exec 자체가 아님).

으아아아

마지막으로 프로그램의 종료 코드를 확인하세요:

으아아아

보세요. 이는 a) 종료 코드가 8비트 계산 장벽을 초과하지 않는 경우와 b) ​​실행기가 성공을 나타내기 위해 137을 사용하지 않는 경우에만 작동합니다(어떻게...흥미롭습니까?!). 나에게는 두 주장 모두 그다지 설득력이 없어 보입니다. 전자는 치명적인 세마포어가 이 범위를 초과해서는 안 되기 때문입니다. 후자는 (i) 사용자 문제이고, (ii) 이러한 종료 ​​코드가 실제로 유지되며(제 생각에는 그렇습니다.), (iii) 로컬이나 다른 곳에서 프로그램을 실행하면 동일한 문제가 발생하기 때문입니다.

제가 볼 때 가장 큰 장점은 실행자에게 세분화된 종료 상태를 보고하는 기능입니다. 신호에 의해 종료된 모든 프로그램 인스턴스를 보고하지는 않습니다. 예를 들어, 프로그램이 SIGTERM을 처리하고 깔끔하게 종료할 수 있는 경우 LXD는 이를 감지하고 프로그램이 신호에 의해 종료되었음을 보고하는 쉬운 방법이 없습니다. 종료 코드 0을 받게 됩니다.

3. 전달 신호 별로 재미없을 수도 있지만(누군지 누가 알겠는가), 매우 유용하다고 생각합니다. SIGKILL 사례에서 볼 수 있듯이 SIGKILL은 lxc exec 명령 자체가 아니라 실행자에게 전송되어야 한다고 명시적으로 명시했습니다. 이는 프로그램에서 SIGKILL을 처리할 수 없기 때문입니다. 프로그램이 할 수 있는 유일한 일은 지금처럼...이 예에서처럼...즉시 죽는 것입니다. 그러나 프로그램은 SIGTERM, SIGHUP' 및 SIGUSR1 및 SIGUSR2와 같은 다른 많은 신호를 처리할 수 있습니다. 따라서 lxc exec`에 의해 처리될 수 있지만 실행기가 아닌 신호를 보내는 경우 최신 버전의 LXD는 해당 신호를 실행기에 전달합니다. 이는 스크립트에서 매우 편리합니다.

어쨌든, 이 짧은 lxc exec 기사/횡설수설이 도움이 되었기를 바랍니다. LXD를 즐기세요. 미친 듯이 아름다운 짐승과 함께 노는 것입니다. 온라인 실험(https://linuxcontainers.org/lxd/try-it/)을 시도하고, 개발자의 경우 여기(https://github.com/lxc/lxd)를 찾아 패치를 보내주세요.

서명을 위해 CLA가 필요하지 않으며 "서명자" 줄이 있는 한 커널 스타일을 따릅니다.

---

위 내용은 lxc exec: 독특한 매력을 탐험해보세요의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!