init의 가장 큰 단점은 태스크가 직렬로 실행된다는 것이다. 그래서 I/O가 있는 작업은 많으면 부팅 속도가 느려지게 된다. 그래서 upstart는 이벤트 기반으로 작성되어 비동기로 작업을 처리한다. 그리고 sysv 방식의 init에 비해 설정이 간편하다.

대부분의 리눅스 최신 배포판들은 systemd가 대부분 설치 되어 있고, 설치가 안되어 있더라도 패키지로 설치할 수 있다.

sshd로 예를 들어 보면 우분투 배포판에는 /etc/systemd/system/sshd.service 파일이 다음과 같이 작성되어 있다.

 systemctl start sshd.service
 systemctl stop sshd.service
 systemctl restart sshd.service

systemd에서는 journalctl 명령으로 유닛의 로그들을 확인할 수 있다.

• -b 옵션을 주어서 마지막 부팅 이후의 로그를 확인한다든지,
• -f 옵션을 주어서 tail -f 와 같은 기능을 할 수도 있다.
• –since=today 와 같이 사용하여 오늘의 로그를 확인할 수도 있고,
• -p err 를 사용해서 특정 레벨의 로그만 볼 수도 있다.
• -u <unit name>으로 특정 유닛의 로그만 확인도 가능함.

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

좋은 init 시스템은 다음과 같은 특성을 가져야 한다

• 적게 시작할 것
• 가능한 한 병렬로 처리할 것

그런데 upstart는 의존성을 설정할 수 있어서 서비스 간에 의존성이 설정되어 있으면 의존성 순서대로 실행이 된다. 기껏 비동기 로직을 적용했는데 결국 직렬화를 해야 하니 성능상의 이득이 줄어든다. 그리고, 당장 필요하지 않은 서비스도 올려두게 되므로 처음부터 많은 프로세스가 뜨게 된다.

반면, systemd는 많은 서비스가 on-demand로 뜰 수 있다. 예를 들어 sshd는 부팅할 때 띄우지 않고 있다가 22번 포트로 요청이 오면 그 때 띄우는 것이다. 의존성도 이런 식으로 설정된다. 그러니까 부팅 속도도 빠르고, 불필요한 서비스는 올라가지 않아서 시스템 자원도 아낀다. 시스템 자원을 아낀다는 점은 애플리케이션 서버의 프로세스를 관리하는 입장에서도 유익하다.

시스템 내부적으로 systemd, upstart, init.d 어느 것을 쓰던지 간에 사용자는 공통적으로 service 스크립트만 사용하면 된다.