systemd

새로운 PID 1, systemd ?

ConsoleKit(udev, mdev, dev) 변천 과정에서 생기는 방식으로 추정됨.
즉 부팅시 프로세스 관리 방법을 변경 되어진다. Systemd 방식

데비안이 다음 버전 init으로 systemd를 선택했고 우분투도 따라가는 것 같다.
RHEL - 버전 7부터
CentOS - 마찬가지
Fedora - 가장 처음 systemd를 기본으로 채택
Arch
openSUSE
SLES - 버전 12부터
Debian
Ubuntu - 채택
systemd가 새로운 대세가 된.

ConsoleKit
- Session
  하나의 부모에서 파생되는 특정 프레세스들의 집합,
  환경 변수를 공유하므로 한 유저 이상이 같은 세션을 공유하는건 불가능함.

- Seat
  Sear는 여러 세션과 하드웨어 자원을 엮어놓은 상위 집합이라고 할 수 있다.
  기존 권한관리 시스템을 이용하면 그룹이나 오너가 아니면(보통 root) 하드웨어 자원을 사용하기가 어렵고 보안상의 문제도 있었지만,
  이를 해결 할 수 있는 방법으로 seat를 통해 하드웨어를 자원을 이용할 수 있게 하는 것 같다.(는 내 생각)

보통 이런 방식으로 보안 로그를 확인 한다.
즉, 보안에 관련된 프로세스(서비스하고 있는 프로세스)에 대한 로그를 만들어 그 로그를 보고 보안상에 이슈를 확인하는 방식으로
보안 장비들이 만들어진다.

systemd와 consolekit를 같이 설치할 수 없다는 에러메시지 둘중 하나를 선택해서 사용해야 한다.
consolekit는 더이상 관리되지 않기 때문에 안쓰는게 좋다는 얘기가 보였다.

systemd 가 기존의 init 시스템인 OpenRC 를 대체한다는 점이다.
즉 시스템의 부팅을 관장하는 프로그램이 바뀌는 것이 때문에 무턱대로 설치할 수도 없는 노릇이었다.
그래서 우선 systemd 로 왜 바꾸는지, 그리고 이게 도데체 무엇인지 좀 알아봤다.

여기서 부터 퍼온글인데... 2014년에 전리한 문서라서. 출처를 모르겠음.

systemd는 오랫동안 사용되어 온 shell script 기반의 init 시스템을 대체하기 위해 만들어졌다.
가장 큰 특징은 부팅시에 띄워야 하는 서비스 수를 최대한 줄이고,
서비스 간의 의존성을 없애서 서비스들을 병렬로 실행하게 함으로써 부팅속도를 획기적으로 개선했다는 점이다.
가령 bluetoothd 와 같은 daemon은 블루투스 동글이 접속되지 않은 이상 꼭 떠야할 필요는 없다.
즉 그것이 필요할 때까지 최대한 기다려서 띄우는 방식이라 꼭 부팅 때 실행할 필요가 없게 만든 것이다.
또 서비스 간의 의존성이란, 예를 들어 D-Bus가 실행되려면 로그시스템인 syslog가 먼저 준비되어 있어야 하는 경우처럼 순차적으로 꼭 실행해야하는 것을 의미한다.
하지만 systemd는 이 부분을 각 서비스가 의존하고 있는 선행 서비스에서 꼭 필요한 부분이 그 서비스 전체가 아니라 소켓이라는 사실을 이용하여 해당 소켓을 먼저 생성해 두고,
경우에 따라 들어오는 시그널은 소켓 버퍼에 쌓아두었다가 해당 서비스가 준비 완료되면 그것을 처리하게 해주는 방식으로 의존성을 낮추었다고 한다.

암튼 이런 기발한 방법으로 시스템의 부팅속도를 높였다.
이런 장점 외에도 대부분 c로 구현되어 있어서, 실행중 사용하는 다른 유틸리티들 때문에 수시로 포크가 일어나는 shell script 기반의 실행속도 보다 훨씬 빠르다고 한다.
이런 저런 이유로 최근 배포판들의 대세가 된 듯한데…

이거 반대하는 쪽도 꽤 있나보다.
systemd 메인개발자 중 한명이 PulseAudio 개발자인데 이걸 싫어하는 사람들이 systemd도 싫어하는 듯 하다(나는 PulseAudio의 내력을 잘 몰라서 뭐가 문제인지 모르겠다).
그런데 그들의 주장 또한 일리가 있는 듯 한다.
우선 systemd가 이식성이 낮아서 리눅스에만 적용할 수 있다는 점이다.
Debian의 경우
커널을 리눅스 뿐만 아니라 FreeBSD나 Hurd 버전도 있기 때문에 systemd을 default로 적용하기 어렵다고 한다.
또 다른 이유로는 소켓 preallocation 관련하여 각 데몬들에 패치를 적용해야한다는 점이다.

만약 Systemd를 사용한다면
systemd로 바꾸게 되면 기존의 SysVinit - /sbin/init은 물론 /etc/init.d/*, /etc/rc*.d 이런 디렉토리에 있는 데몬 관리용 스크립트들과 배포본별로 제공하던 런레벨 관리자도 사용하지 않습니다.
패키지별로 systemd 방식의 설정 파일을 /usr/lib/systemd/ 아래에 설치하고 systemctl 명령어를 통해 시작/중지/등록/삭제 작업을 합니다.
데몬의 상태를 관리하는 일도 합니다.
죽거나 멈추면 다시 시작해주고 다양한 조건에 따라 중지하거나 시작하거나 하는 일도 합니다.
설정 파일의 형식은 .ini 파일이나 .desktop 파일 하고 비슷합니다.
각 데몬의 출력 - 로그는 journald에서 일괄적으로 처리해서 journalctl 명령어로 조회하거나 별도의 로그 데몬으로 전달할 수 있습니다.

그런데 단순히 /sbin/init을 대체하고 데몬 관리만 하는 것은 아니더군요.
세부적인 설명은 제가 기술이 짧아서 언급하기 힘듭니다만 그동안 systemd 관련 글타래를 훑어본 결과로는 온갖 바닥 일은 systemd가 다 할 수 있는 것 같습니다.

동적인 장치 관리, 사용자 인증, 권한 관리, 프로세스별 자원(cgroup) 관리, 로그 관리, 사용자별 서비스 등등 별 별거 다 하더군요.

systemd의 구현 방식이 좋다 나쁘다 할 지식은 없지만 어쨌든 systemd 광고대로 잘 되면 배포본별로 제각기 다른 시스템 관리 작업이 통합된다는 점은 저한테 큰 장점으로 보입니다.
mysql, apache 다시 시작하는데 배포본마다 다른 방법을 사용해야 한다는 게 좋은 일만은 아니질 않습니까?
어차피 패키지 업스트림은 다 같은 데서 가져다 쓰는 데 사용하는 방식도 통일될 수 있다면 좋은 일이 아닐까 합니다.

데스크탑 사용자의 입장에서 systemd로 돌아가는 배포본을 써보면 당장 피부에 와 닿는 느낌은 없습니다.
아치 리눅스 써 본 경험에 의하면 시스템 종료가 우분투보다 빠르다?
그것이 systemd 때문인지도 확실하진 않습니다. 부팅도 우분투와 비교하여 좀 빠른 감은 있는데 큰 차이는 아니었습니다.

systemd의 관한 논쟁 중에 재밌는 점은 개발자
- Lennart Poettering -
개인에 관한 공격이 많다는 겁니다. 이 분은 pulseaudio 개발자이기도 한데 개발 과정에서 안 좋은 인상을 남겼는지 삐딱하게 보는 시선이 상당히 많이 보였습니다.

기술적인 측면이 아닌 개발자 개인의 성향에 관한 비판이 어떤 면에서는 유치한 공격이 아닌가 할 수도 있습니다만 시선을 바꿔서 바라보면 또한 일리가 있습니다.

systemd가 담당하는 부분은 커널을 제외하고는 가장 핵심적인 부분이고 밑바탕이라고 볼 수 있습니다.
한 번 선택하면 쉽게 다른 패키지로 대체할 수 없고 적어도 5년, 10년은 바라봐야 하는 그런 패키지라고 생각합니다.
이런 중요한 패키지의 핵심 개발자가 커뮤니티와 의사소통이 잘 안 되고 프로젝트 관리 방식이 편협하거나 독재적인 성향이 강하다면 큰 골칫거리가 될 수 있습니다.
그래서 개발자의 개인적인 성향도 해당 소프트웨어를 선택하는 데 중요한 이유가 되는 것이 맞는다고 생각합니다.

Lennart의 개발자로서의 성향은 잘 모르나 여하튼 pulseaudio를 사용하면 받은 인상은 나쁘지 않기 때문에 전 별다른 유감은 없습니다.

기술적인 측면에서의 비판은 '한 가지만 잘하자'는 유닉스의 철학에 너무 어긋나는 설계다,
너무 많은 일을 한군데서 담당한다는 의견을 자주 보였습니다. 이 문제는 '한 가지'를 어떻게 정의하느냐에 따라 다양한 해석이 가능할 것 같습니다.

기존의 sysv 스타일의 시스템도 많이 다뤄 보시고 systemd도 만져 보신 분들이 있으신가 궁금합니다.
어떤 장단점이 있는지 들어 보고 싶네요.

제 경우 손에 잘 달라붙는 유용한 명령들은 journalctl로 특정 서비스 로그 골라보기하고 systemctl status로 역시 특정 서비스 상태 골라 보기가 맘에 들었습니다.
이전에도 가능했던 작업이지만 더 편하게 볼 수 있어서 좋더군요.

데비안이 어떤 결정을 할 지도 참 궁금합니다.
데비안과 우분투도 systemd를 선택하면 리눅스 세계에서 꽤 기념비적인 '대통합'으로 기억될 것 같습니다.

정리하면.
systemd로 서비스 관리
서비스 로그 확인 명령어: journalctl
프로세스 상태 확인: systemctl status