SystemD 이해하기

@xiep 귀하의 의견에 더 이상 동의 할 수 없습니다.

@juanfgs 당신은 읽는 유일한 사람인 것 같습니다. 적어도 나는 당신에게 박수를 보냅니다. 그러나 당신은 제 의견에있는 매우 중요한 것을 읽어야합니다. 그것은 중요하지 않습니다.

»NIH 어디? 좋은 늙은 레나 트는 트롤을 좋아하고 큰 것을 좋아하는 것 같습니다. "

나는 그가 무고한 이유로 그것을 썼다고 생각하지 않는다. 그는 그것이 XNUMX 월의 바보의 날 (나쁜 기분)에 대한 또 다른 레나 트 농담이라는 사실과 /, / etc와 그 밖의 모든 것을 /로 바꾸는 것에 대한 그의 열정을 알고 있었다. 리눅스. 🙂

추신 : 고맙지 만 영어를 연습 할 필요는 없습니다. 저는 6 살 때부터이 언어를 사용하고 있습니다.
aaahh 및 다른 모든 것이 사실입니다. 확인하십시오 🙂

@juanfgs, 구체적으로 이것에 대한 당신의 말에 당신을 데려갑니다.

«그리고 현실은 대부분의 안티 -systemd가이 테스트를 통과하지 못한다는 것입니다. 심지어 어떤 이유로 든 뒤에있는 사람들보다 더 많은 것을 알고있는 소수의 사람들이 있습니다 : Debian, Fedora, Archlinux, Linux 커널, 전체 그놈 project 아마도 KDE 프로젝트 일 것입니다. systemd, SUSE 및 long 등에 대해 불평하지 않았기 때문입니다.

그럼에도 불구하고 그의 독하고 유리한 연설은 그가 성취하는 유일한 것은 분열, 문제 및 기타를 생성하는 것입니다. Xorg, NetworkManager, PulseAudio로부터 위협을 받았기 때문에 그들이 마침내 BSD로 전환하기를 기다릴 수 없다는 점입니다. 기술적 인 무지 때문인지 아니면 불평하지 않았는지 모르겠습니다. "

그래서 당신에 따르면, 우리 모두는 시스템에 반대하는 우리 모두는 독이 있고 유리하며 우리가 성취하는 유일한 것은 분열, 문제 등등입니다. 제가 여기서 읽을 수 있었던 가장 큰 분노라고 말씀 드리겠습니다. 나는 시스템의 구조적 문제가 드러날 때 프로 시스템 드가 왜 괴롭히는 지 모르겠다. 이것은 분명히 어느 시점에서 그들에게 영향을 미칠 것이다. 왜냐하면 지금 그들에게 아무 일도 일어나지 않았을 수도 있기 때문이다.하지만 어느 시점에서는 그렇게 될 것이다. 그런 다음 일부 시스템화 방지 시스템은 그들이 여러 번 말한 단어를 상기 시켜줄 것이고 아무도 그들을 막지 않았으며 아마도 다른 시스템화 방지 시스템이 그들에게 도움을 줄 것입니다.

개인적으로 저는 systemd를 좋아하지 않지만 이것이 init를 사용하지 않는다는 의미는 아닙니다. 사용해야 합니다. 왜냐하면 정확하게 제 직업에서 해당 init가 있는 기계를 만져야 한다면 어떻게 처리해야 하는지에 대한 지식이 있어야 하기 때문입니다. 그것. 그리고 개인적으로 저는 Archlinux에 온 이후로 심지어 Debian과 Gentoo에서도 사용해왔습니다. 그러니 systemd를 사용하지 않아서 제 비전이 편파적이라고 말하지 마세요. 저는 그것을 사용해왔고 그것이 얼마나 형편없는지 알고 있습니다. , 여기 포럼에서 누군가를 도와야 한다면 DesdeLinux 또는 IRC 또는 Debian 목록(내가 가장 오랫동안 사용하고 있으며 여전히 내 작업에 사용하는 배포판)에서 나는 기꺼이 그것을 할 것입니다. 왜냐하면 정확하게 내가 Linux 커뮤니티에 대해 마음에 드는 점이 있다면, 차이점은 항상 도움입니다.

이제 BSD로 전환하는 것이 가능합니다.하지만 systemd가 너무 악성이되어 다른 옵션을 사용할 수없는 경우에만 그렇게 할 것입니다. 그 동안 Linux에 머물면서 많은 것을 포함하여 모든 광기를 비활성화합니다. Cgroups 물건.

Glibc에는 아무도 숨길 수없는 버그가 있습니다. 커널과 수백 개의 실행 파일에 영향을주는 거대한 Glibc 버그가 있습니다. Glibc와 systemd의 차이점은 전자는 수천 개의 소프트웨어 프로젝트를 바이너리로 변환 할 수있는 기반이고 systemd는 init이며 그 목적은 안정적이고 입증되었으며 실질적으로 오류가없는 부분이라는 것입니다. 뿐만 아니라 Glibc는 수백 가지의 서로 다른 하드웨어 아키텍처 (CPU), 다양한 최적화 플래그 및 CPU의 고유 한 특성, 다양한 형태의 소프트웨어 최적화, systemd보다 훨씬 더 힘들고 어려운 작업에 맞게 조정해야합니다. 두 프로젝트를 같은 규모로 비교할 수있는 방법은 없습니다.

GCC도 마찬가지입니다. GCC는 여러 언어 (비공식 언어를 포함하여 총 13 개)를 지원하는 컴파일러이며 Glibc와 매우 유사한 특성을 가지고 있으며 많은 아키텍처 (버전 70의 경우 4.9 개 아키텍처), 바이너리 최적화를 지원합니다. flags, CPU 최적화 플래그 및 기타 많은 기능. 이제 그들은 동일한 난이도, 즉 init가있는 컴파일러에 있습니다. 그 대답은 분명합니다. systemd가 C로 시작하고 많은 GCC 코드가 어셈블러에 있거나 바이너리로 작업하기 위해 어셈블러를 사용해야합니다.

GCC 및 Glibc 결함은 무엇입니까? 확실한. Linus조차도 그들에게 공격을가했지만 GCC와 Glibc에서는 시스템에서 종종 잊혀지는 긍정적 인 무언가를 가지고 있습니다. 즉, 버그보고, 버그 확인, 버그 수정 등이 있습니다.

게다가, Kay Sievers가 커널 cmdline을 깨 뜨렸을뿐만 아니라 "generic is generic"을 종료하고 싶었다는 사실을 누구도 잊지 않습니다.

나는 당신이 잘못 읽고 분석했다고 생각합니다 (분석이 중요합니다) 또는 당신은 그것을 할 기회조차주지 않았습니다. 두 프로세스가 정보를 전달한다고해서 시스템이 중단되는 이유는 아니지만 네트워크 제어, 로그 또는 코어 덤프와 같은 동적 동작이있는 바이너리가 있고 정보를 init에 직접 전달하면 상황이 잘못 될 수 있으며 잘못 될 수 있습니다. 바이너리 중 일부가 깨지면 나머지 부분을 깨뜨릴 가능성이 훨씬 더 높고 이는 매우 현실적이며 최근에 발생한 커널 cmdline 크래시, Nvidia 개발자가 systemd-212 덕분에 가지고 있었던 acpi 문제, 모든 것이 내가 말하는 것의 샘플.

@anonymous, Linux에서 TTY 문제가 어떻게 진화하는지보고 싶습니다. CONFIG_VT 코드가 나오면 VT를 두 개의 잘 구별 된 부분 (커널 공간과 사용자 공간)으로 나누기 위해 사용자 공간에서 VT를 제어하는 ​​도구가 필요하며 systemd-consoled는 나머지 부분을 끌어 당기는 강력한 종속성으로 사용할 수 있습니다. 시스템이 작동 할 수 있도록 시스템 구성 요소를 설치해야하는 필요성에 대한 배포판입니다. 내가 말하는 것은 과장이 아니라 매우, 매우 큰 가능성이며, 정말 걱정 스럽습니다. KMSCon과 같은 다른 프로젝트가 있지만 대부분의 데스크톱과 배포판이 systemd를 선호한다면 KMSCon과 같은 것은 많은 사람들이 생각하는 것보다 빨리 죽을 수 있습니다.

@ 익명의 질문은 CONFIG_VT를 제거하는 것이 결국 (내가 읽은 내용에서) 전체가 될 것입니다. 즉, 커널에서는 기본 요소 만 남아 있고 나머지 도구는 사용자 공간에 있습니다. 나쁘지 않습니다. 반대로 커널에서 오래된 코드를 많이 제거하고 유지 관리가 더 쉽고 훨씬 더 구성 가능합니다 (콘솔에 대한 전체 KMS / DRM 지원). 확실히 처음에는 두 시스템이 모두있을 것이지만 장기적으로 (15-20 개의 릴리스) 커널을 종료 할 수 있으며 더 새롭고 더 나은 지원 코드를 선호하는 많은 도구가 더 이상 이러한 코드를 지원하지 않을 수 있습니다.

이제, 당신은 만약 systemd가 그것을한다면 50 개 이상은 그것을 할 수 없기 때문이라고 말합니다 (나는 50 개 이상의 애플리케이션을 상상합니다). 글쎄, 우리가 KMSCon (이 의미에서 가장 오래된 프로젝트)의 강력한 종속성을 본다면 그들은 libudev (곧 systemd에 결합 될 코드, 지원되지 않을 것이며 자체적으로 작동하는 경우 systemd와 충돌 할 것입니다), libdrm , libxkbcommon, libtsm 및 systemd 자체가 다중 시트를 처리하므로이를 보면 GNU / Linux OS가 문제없이 작동하는 데 필요한 많은 도구를 스스로 가져 가면서 상황이 어떻게 형성되고 있는지 알 수 있습니다.

@ 익명은 확실히 다른 가능성입니다. eudev는 이와 관련하여 더 큰 힘을 얻고 다른 도구를 선택할 수있는 옵션을 계속 열어 둘 것입니다.

추신 : 말씀하신대로 VT가 fbdev와 함께 KMS / DRM의 장점을 어떻게 활용하는지 보는 것은 흥미로울 것입니다 😀

@dariem은 아이디어를 얻었는지 확인하기 위해 간단한 방법으로 설명했습니다.

당신이 말하는 것은 확실히 모듈 식 프로그램과 프로세스에서 항상 기대되는 행동입니다. 모듈화는 두 프로세스를 분리하고 자체 메모리 공간을 차지하고 어떤 수단 (IPC 등)으로 통신하여 문제가 발생해도 나쁜 일이 발생하지 않도록하는 목적으로 구현되었습니다. 시스템은 중단없이 계속 작동 할 수 있습니다. 잠재력과 현재 컴퓨팅에 부여한 엄청난 신뢰성으로 인해 확실히 큰지지를받은 이론. 자, 이것은 항상 사실이 아닙니다 (인생이 항상 아름답지는 않습니다). 그리고 저는 여러분이이 사건의 희생양이되었다고 생각합니다 (사용하는 OS에 관계없이 모든 사람에게 해당됩니다). 몇 가지 예입니다.

첫 번째는 Xorg (systemd와 같은 모듈 식 프로세스)와 함께 사용되며, 때로는 드라이버에 미쳐서 그래픽없이 충돌을 일으키고 나머지 시스템은 예상대로 계속 작동합니다 (축복받은 모듈성 😀). 지금까지 모듈 식 프로세스가 시스템을 중단 할 필요가 없다는 우리의 이론은 잘 작동합니다. 그러나 (항상 일부가 있지만) 때때로 Xorg는 광기 이상의 무언가를 제공하며 (마우스 제어에서 그래픽 드라이버에 이르기까지 다양 할 수있는) 이상한 이유로 Xorg 충돌을 일으킬뿐만 아니라 가장 아름다운 커널 패닉을 제공합니다 ( 그리고 Picasso와 같은 모니터의 낙서)를 상상할 수 있습니다. 모듈 방식에 상관없이 프로세스가 다른 프로세스와 정보 / 데이터를 상호 통신하고 교환하면 그 중 하나에서 문제가 발생하고 어떤 이유로 든 오류를 올바르게 처리 할 수없고 데이터가 잘못되었거나 단순히 손상되었다는 단순한 사실 때문에 문제의 프로세스가 영향을받을 가능성이 증가하고 그 후 재앙이 발생합니다.

이것이 일어날 수 없다고 생각한다면, Xorg, mesa, nouveau 및 커널의 drm / kms 드라이버에있는 오래된 오류에 대한 버그 보고서 (하나는 데비안에서 내 것이고 몇 장의 사진이 있습니다)를 남겨 둡니다. **를 별도로 실행하고 모듈 식 **을 사용하면 적어도 상황에서는 잘 어울리지 않습니다.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742930
https://bugzilla.redhat.com/show_bug.cgi?id=901816
https://bugzilla.redhat.com/show_bug.cgi?id=679619

이제 systemd를 사용하여 다른 예를 들겠습니다. 우리의 오래된 Sysvinit은 오래되었지만 / etc / fstab에 파티션 항목이 있으면 (시스템에 중요하지 않은 경우 / mnt / Disk160GB를 이해하십시오) 매우 신뢰할 수 있다는 특징이 있습니다. 어떤 이유로 마운트되지 않은 경우 마운트를 건너 뛰고 경고 메시지를 표시하고 부팅 프로세스를 계속했습니다. 이제 systemd는 모듈성에도 불구하고 다른 이야기입니다. / etc / fstab에 항목이 있고 어떤 이유로 systemd가 마운트 할 수 없다고 판단하면 파티션을 사용할 수있을 때까지 기다릴뿐만 아니라 일반적인 프로그래밍 동작 ) 조립을 위해 시간이 끝나면 시스템이 중지되고 복구 모드로 들어가 / etc / fstab에서 해당 행을 제거하는 것 외에는 아무것도 할 수 없습니다. 실제로 뭔가 실패합니다. 부팅시 자동 마운트하는 동안 더 이상 작은 세부 사항이 없으며 전체 프로세스가 중지됩니다. 처음에는 (systemd-) 덤프가 방금 나타나고 다시 시작해야했기 때문에 작은 세부 사항이 더 이상했습니다. 세부 사항을 살펴본 사람이 알려줍니다.

내가 줄 수있는 또 다른 예는 systemd의 coredumpd입니다. coredumpd는 기본적으로 모든 정보를 journald에 전달하여 후자가 캡처 된 정보를 디스크에 기록하도록합니다. 지금까지 우리는 systemd의 모듈성을 유리하게 사용하고 있습니다. 그러나 때로는 코어 덤프가 매우 크고 너무 커서 몇 GB를 차지할 수 있고 정보를 코어 덤프에서 journald로 전달한 다음 디스크로 전달하는 과정에서 Xorg가 작동을 멈추고 심지어 커널과 같은 이상한 일이 발생합니다. 패닉. 물론 systemd에서만 발생하는 것이 아니라 설계 방식이 실패 요인을 증가시키고 기타 불쾌한 세부 사항 (메모리 소비 증가, 로그 손상, 불완전한 덤프 등)을 생성합니다. KDE 코어 덤프로 작업해야했던 사람은 이와 같은 여러 에피소드를 통해 덤프 파티션의 / etc / fstab에 동기화 옵션을 사용하는 것의 중요성을 이해했을 것입니다. 덤프를 처리하기 위해 다른 옵션을 사용할 수 없다는 사실을 분명히 싫어할 것입니다. 시스템이 설치되었습니다. systemd-coredumpd에서 발생할 수있는 일의 예입니다.

https://bugs.archlinux.org/task/41728

이제 끝내려면 :

모듈 식 프로그램과 프로세스로되어 있지 않습니까? 예, 모듈 식입니다. 커널은 내가 여기서 이야기 한 유일한 모 놀리 식이지만 모듈 (LKM)도 허용하므로 기본 설계 형태가 이러한 유형의 구조로 설계되지 않았지만 일종의 하이브리드 커널이 될 것입니다. 특정 상황에서는 약간 불안정합니다.

모듈화로 인해 문제가 발생하더라도 내 프로세스와 시스템이 충돌하는 것을 방지 할 수 없습니까? 사실, 모듈화는 높은 수준의 안정성과 신뢰성을 달성하기 위해 고안된 척도이지만 100 % 오류가없는 척도는 아닙니다. 왜냐하면 무언가 잘못 될 수 있다면 모듈 방식에 관계없이 단순히 잘못 될 것이기 때문입니다. 현실.

커널에 추가 된 cgroup 및 기타 옵션을 사용하려면 systemd가 모든 것을 제어해야합니까? 완전히 거짓입니다. 그것은 전혀 필요하지 않습니다. systemd는 현재 가지고있는 서비스 수를 인계 할 필요없이 시스템에있을 프로세스와 데몬에 cgroup의 시작 및 할당을 제어하는 ​​인터페이스를 남겼을 수 있습니다. 가장 좋은 예는 다음과 같습니다. OpenRC는 또한 cgroup을 사용할 수 있으며 그 이유 때문에 해당 작업을 수행하는 데 침입하지 않습니다.

systemd에 대해 말할 때 편견과 두려움이 무엇입니까? 나는 그가 그것을 어디서 얻었는지 모르겠다. 왜냐하면 내 대답을 보았을 때 나는 그것을 두려워하지 않기 때문에 나는 제 XNUMX 자의 의견에 의존하지 않고 체계적이고 이미 좋아하지 않는 측면에 대해서만 이야기합니다.

마지막으로, "프로그래머가 예기치 않은 입력 및 출력을 처리 할 수있는 코드를 포함하지 않는 데 너무 나빴다면 그것은 다른 일입니다."

잘못된 데이터 입력으로 인해 프로그램이 손상 될 수있는 가능한 모든 방법을 처리하는 코드를 포함하지 않은 프로그래머는 나쁘다고 말하는 것은 당연합니다. 프로그래머가 아무리 훌륭하더라도, 사람은 오류가없고 안전한 프로그램을 설계 할 수 없습니다. 항상 실패가있을 것입니다. 어떤 식 으로든 밝혀 질 것이며, 그렇게되면 덕분에 그럴 것입니다. 사용 중, 취약점을 악용하는 해커 나 크래커, 코드 검토 및 감사 또는 프로그래머가 신뢰할 수있는 기타 수단에 의한 임의의 실패. 그런 말을하기 전에 단어를 측정하는 것이 좋습니다.

인사말.