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

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

• Debian debates systemd
• https://wiki.debian.org/Debate/initsystem/systemd

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

• http://www.freedesktop.org/wiki/Software/systemd/
• systemd - The Biggest Myths

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