새로운 PID 1, systemd 어떻게 생각 하세요?

마잇의 이미지

systemd의 장단점에 대해서 논의하는 격렬한 글타래는 여기저기서 많이 봤는데 이 두 군데만 보시면 웬만한 의견은 다 담겨 있는 것 같습니다.

다음은 systemd 공식 프로젝트 페이지와 systemd에 빈번하게 제기되는 비판 중 오해라고 생각하는 부분에 대해서 개발자 자신이 직접 해명한 글입니다.

현재 다수의 배포본에서 systemd를 기본 init 시스템으로 채택했습니다.

  • RHEL - 버전 7부터
  • CentOS - 마찬가지
  • Fedora - 가장 처음 systemd를 기본으로 채택
  • Arch
  • openSUSE
  • SLES - 버전 12부터

굵직한 배포본들이라 파생된 배포본들도 꽤 있을 것이고 마찬가지로 systemd를 사용하게 될 것입니다. Gentoo, Debian, Ubuntu, Slackware는 systemd로 이전하지 않았습니다.

제 추측으로는 데비안만 systemd로 결정하면 우분투도 따라갈 것 같습니다. 스마트폰용 우분투, Mir, XMir, Unity 8 개발하느라 우분투는 지금 이런 큼지막한 작업에 손수 나서서 손댈만한 인력이 없기도 할 것 같고 내년 4월에 나오는 14.04가 LTS 버전이라 당장 큰 변화는 반기지 않을 것 같습니다.

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를 선택하면 리눅스 세계에서 꽤 기념비적인 '대통합'으로 기억될 것 같습니다.

마잇의 이미지

읽기 좋게 줄바꿈 좀 다시 할려고 했더니 편집이 안되는 건지 제가 못 찾는 건지...

https://gist.github.com/mait/8071731

이 곳에서 읽으셔도 됩니다.


--
마잇

baimouths의 이미지

젠투에서 systemd 아주아주 짧게 테스트해봤는데 부팅은 조금 더 빨라지더군요... 아주 조금이요
그 외엔 모르겠습니다
좀 다를 뿐 딱히 편하다거나 그렇다고 불편하다거나 한 건 없었습니다
큰 바람이 불어오지 않는 한 그냥 쓰던대로 쓰렵니다

dontdieych의 이미지

데비안이 다음 버전 init으로 systemd를 선택했고 우분투도 따라가는 것 같습니다.

RHEL
SUSE
Debian
Ubuntu
Arch

systemd가 새로운 대세가 되었네요.

http://www.markshuttleworth.com/archives/1316

andysheep의 이미지

https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet

How to Crash Systemd in One Tweet

The following command, when run as any user, will crash systemd:
NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

After running this command, PID 1 is hung in the pause system call. You can no longer start and stop daemons. inetd-style services no longer accept connections. You cannot cleanly reboot the system. The system feels generally unstable (e.g. ssh and su hang for 30 seconds since systemd is now integrated with the login system). All of this can be caused by a command that's short enough to fit in a Tweet.

Devuan 1.0 (Debian without systemd)
amd64 station: AMD FX(tm)-6100 Six-Core Processor, 8 GB memory, 1 TB HDD
amd64 laptop: HP Touchsmart

글쇠판: 세벌 최종식, 콜맥 (Colemak)

지리즈의 이미지

요즘 배포본의 가장 핵심적인 시스템인데도 불구하고 도큐먼트가 친절하지 않아요. 이게 개발자에게 공격이 가는 가장 큰 이유인 것 같습니다.

게다가 상대적으로 새롭게 시작된 프로젝트들이다 보니까 변화가 있고 이러면 obsolete가 되는 도큐먼트가 종종 생긴다는 것도 문제입니다. 배포본 전문적 개발자들은 다들 이해하고 적용하지만, 비전문적인 유저로서 커스터마이즈를 하기 시작하면 재앙이 시작되죠. 스크립트 기반이라면 그나마 소스 보기가 낫지만, 이게 바이너리 차원이 되버리면 이것도 쉽지가 않지요. 특히 systemd같은 경우는 콘솔에서 디버깅할 때와 실제 부팅할 때 결과가 다른 경우가 생기는 것도 심각한 문제입니다.
부족하거나 부정확한 도큐먼트, 이해하기 어려운 시스템으로 좌절을 겪다가 보면 증오감이 생기게 될 수 밖에 없습니다. 성능이 좋냐 안좋냐에 대한 문제가 아니라 한 인간으로서 어떠한 대상에 대해서 신뢰할 수 있느냐 아니냐 하는 감정적인 문제로 연결될 가능성이 높습니다.

한때 pulseaudio가지고 고생하다가 요즘들어 systemd가지고 다시 고생하기 시작해서 푸념 한번 적어 봤습니다.

There is no spoon. Neo from the Matrix 1999.