요새 매우 핫이슈인 systemd에 대해서 알아보도록 하겠습니다.

우분투 진영도 15.04부터는 오랫동안 함께 해왔던 upstart-job을 버리고 systemd를 사용하고 있죠. docker에 최적화된 운영체제인 CoreOS에도 systemd를 사용하고 있습니다.

이때까지 linux는 pid 1, 즉 가장 먼저 실행되어 OS에 필요한 각종 데몬들을 init이었으나, 이 자리를 systemd가 대체할 수 있게 되었습니다.

눈에 띄는 변화는 기존 init에서는 run level이 불필요하게 세분화 되어 0부터 6까지 있었으나, systemd는 poweroff, resque, multi-user, graphical, reboot 5가지로 나누어 지금 현실에 좀 더 적합한 구분을 하고 있습니다. 물론 기존 run level에 익숙한 사용자를 위하여 symlink도 제공하고 있습니다.

우분투 기준으로 봤을 때 데몬을 실행,중지등의 작업을 할 때는 service <service name> start | stop | restart 등등의 명령으로 제어를 했습니다만, systemd를 사용하는 시스템에서는 systemctl start | stop | restart <unit name>으로 관리하게 됩니다.

그리고 upstart-job에서는 데몬들을 service라는 네이밍을 붙였고, systemd에서는 unit이라는 이름을 사용합니다.

upstart-job에서는 <service name>.conf를 /etc/init에 두고 /lib/init/upstart-job을 symlink하는 <service name>를 /etc/init.d에 두어서 서비스를 설치하였습니다만, systemd에서는 <unit name>.service이라는 파일을 systemctl install <unit name>.service 명령으로 설치를 할 수 있습니다.

upstart-job의 <service name>.conf는 독자적인 파일 포맷을 가지고 있습니다만, systemd의 <unit name>.service는 ini 포맷을 사용하고 있습니다.

그 외에도 이때까지 linux 시스템에서 데몬 관리에 필요로 했던 여러가지 기능이 추가 및 개선이 많이 되었습니다.

upstart-job에서 서비스 실행시의 standard output 및 stardard error는 /var/log/upstart에서 확인할 수 있습니다만, systemd에서는 journalctl 명령으로 유닛의 로그들을 확인할 수 있습니다.

-b 옵션을 주어서 마지막 부팅 이후의 로그를 확인한다든지,

-f 옵션을 주어서 tail -f 와 같은 기능을 할 수도 있습니다.

--since=today 와 같이 사용하여 오늘의 로그를 확인할 수도 있고,

-p err 를 사용해서 특정 레벨의 로그만 볼 수도 있습니다.

-u <unit name>으로 특정 유닛의 로그만 확인도 가능합니다.

이 처럼 이때까지 필요로 해서 다른 도구 및 스크립트등을 사용해서 해야만 했던 작업이 기본 기능으로 포함되어있습니다.

다음 글에서는 systemd에 unit을 추가하는 법에 대해서 알아보겠습니다.