2015/05/24

Ubuntu 15.04 systemd 부팅 시간 줄이기


systemd 매번 부팅시마다 fsck 검사하는 문제

우분투 15.04부터 본격적으로 systemd를 채택했으니 여기에 적응할 필요가 생겼다. 기본적으로 매번 부팅할 때마다 fsck가 파티션 별로 file system check를 하다보니 10초 정도를 허비하고 있다는 것을 알았기 때문이다. Ctrl-C로 취소할 수 있다고 메시지가 뜨지만 실제로 Ctrl-C도 동작하지 않는다. 이 두 가지 문제 중에서 첫번째만 해결되면 Ctrl-C가 동작하지 않아도 큰 문제는 없다.

systemd에서는 부팅 후 터미널에서 아래의 명령으로 부팅 시 소요 시간과 서비스(systemd unit service)별 병목 구간을 알 수 있다.

$ systemd-analyze
$ systemd-analyze blame
$ systemd-analyze critical-chain

예전에 fsck 주기를 mount 횟수나 일정 시간 간격으로 설정할 수 있었던 기억이나서 tune2fs를 가지고 별짓을 다 해 보아도 부팅시 fsck가 파일시스템 검사하는 것을 막을 방법이 없었다. 구글링으로 찾은 방법은 /etc/fstab 파일에서 <Pass> 파라미터를 0으로 바꿔주면 해당 파티션은 fsck 검사를 하지 않는다는 것이다. 모든 파티션에 대해 파라미터를 0으로 수정하고 재부팅하니, 과연 10초 정도 부팅속도가 빨라졌다. 뭐 이 방법도 나쁜 방법은 아니지만, fsck를 고생해서 쓰라고 우분투에 넣었는데 안쓰는 것도 좀 미안한 생각도 들고, 왠지 가끔씩은 돌려야 할 것 같아서 더 좋은 방법을 찾아 보기로 했다.

e2fsck time-stamp 문제

우분투 관련 사이트에는 systemd 사용역사가 짧아서인지 문제점을 지적한 글을 찾을 수 없다. 역시, systemd를 처음 채택한 Fedora 관련 사이트에서 이 두가지 문제에 대한 글들을 찾을 수 있었다. fsck 버그란 얘기도 있고 fsck time-stamp 때문이란 얘기도 있다. 실제로 아래의 명령으로 fsck time-stamp 문제가 발생하는 것을 확인할 수 있었다.

$ journalctl | grep -i fsck
May 23 17:20:10 localhost.localdomain systemd-fsck[278]: ROOTFS: Superblock last write time is in the future.
May 23 17:20:10 localhost.localdomain systemd-fsck[278]: (by less than a day, probably due to the hardware clock being incorrectly set). FIXED.
또, 아래 명령으로 리눅스 ext 파티션의 mount와 최종 fsck 시간을 확인할 수 있는데 UTC time으로 로그가 찍힌다.

$ sudo tune2fs -l /dev/sda8

가만히 생각해 보니, Windows와 Ubuntu의 시간을 맞추기 위해 /etc/default/rcS 파일에서 UTC=yes 설정을 UTC=no로 바꾸었다는 것을 깨닫게 됐다. 이 설정은 컴퓨터 내장 시계의 시간 기준이 UTC인지 local time인지를 부팅시에 알려 준다. 추정컨대, H/W clock이 local time으로 설정되어 있어서 fsck 검사시에 local time으로 최종 시간을 파일시스템에 저장했는데 다시 fsck 검사할 때는 이것이 UTC time이라고 생각하기 때문에 발생하는 문제인 듯 싶다. 즉, 우리나라 local time인 KST = GMT+09로 UTC 시간 보다 9시간이 빠르다. 참고로, 시간 설정에 대한 정보는 아래의 명령으로 확인할 수 있다.

$ timedatectl status
$ sudo hwclock --show

문제 해결?

아무튼 /etc/default/rcS 파일을 원래대로 UTC=yes로 저장하고 재부팅했더니 파일시스템 검사 시간이 줄어 들었다. 검사 시간이 줄어드는 정도로는 안되고 아예 검사를 하지 말아야 한다. journalctl 명령으로 확인해 보니, EFI System Partition(ESP)에 대해서만 fsck가 파일시스템 검사를 했음을 알 수 있었다. ESP는 vfat 파일시스템이므로 fsck 검사시간 정보 등을 저장할 수 없다. 예외적으로 이 놈에 대해서만 /etc/fstab의 <Pass> 파라미터를 0으로 설정하기로 하였다. 이 후로 몇번 재부팅해봤는데 더이상 fsck가 돌지 않아서 부팅시간이 10초 정도 빨라졌다.

vfat 빼고는 생기지도 않았을 문제를 해결했다니 느낌이 좀 이상하네...

systemd 부팅 시간 쬐금 더 줄이기

systemd에서는 서비스들을 unit 단위로 관리한다. unit 간에 의존성이 있을 수도 있다. 일단 아래의 명령으로 현재 서비스 unit과 상태를 확인할 수 있다. 상태는 enabled, static, disabled, masked의 4가지가 있을 수 있는데, static은 다른 unit과 의존 관계가 있다고 이해하면 될 듯하다. masked는 disable 시킨건 아니지만 의존 관계를 유지하면서 해당 unit만 disable 시키는 방법인 듯하다. 물론, 부팅 후 특정 서비스 unit을 stop하거나 start 할 수도 있다.

$ systemctl list-units --type service
$ systemctl list-unit-files --type service

그리고, systemd 서비스 unit을 부팅시에 동작하지 않도록 하거나, 다시 동작하도록 하려면 아래의 명령을 사용하면 된다.

$ sudo systemctl disable <unit 명>
$ sudo systemctl enable <unit 명>

앞서 systemd-analyze blame 명령에서 서비스 unit 별로 실행시간 profile을 알 수 있는데 시간이 오래 걸리는 놈들 중 불필요한 서비스 unit을 disable 시키면 된다. 아래 두 놈을 시범삼아 제거해 보았다. 참고로, fsck의 경우도 systemd-fsck@.service를 disable 시킬 수도 있지만 다른 unit와 의존관계가 있었고 아래 두 놈은 의존관계가 없어 보였다.

$ sudo systemctl disable ModemManager.service
$ sudo systemctl disable bluetooth.service

결론

위의 두 놈을 제거후 재부팅했더니 5초 정도 부팅시간이 빨라졌다. fsck까지 포함해서 15초를 절약하게 됐다. 그래서 총 부팅시간이 35초에서 20초 정도로 줄었다는 것이 결론이다. 뭔가 허무한 느낌... 더구나 애초에 /etc/default/rcS 파일을 건드리지 않았으면 fsck에 대한 10초도 빨라진게 아니라는... ㅠ.ㅠ

참고 사항

위에서 우분투 H/W 시간 기준을 UTC로 바꾸고 Windows로 부팅하면 Windows에서는 그 시간을 local time이라고 해석하기 때문에 시간이 UTC time으로 바뀌어 9시간 느린 시간이 표시될 수 있다. 특히, NTP time 서버와 동기화 되지 않을 때 이 문제가 생기는데 Windows Scheduler에서 NTP 서버 동기화 작업을 걸어 주거나, Windows에서도 H/W 시계의 시간 기준이 UTC라고 알려 주는 방법도 있단다. Mac OS X의 경우에는 Unix 계열이므로 리눅스와 마찬가지로 timezone으로 시간을 설정하므로 시간 불일치 문제는 발생하지 않는다.

댓글 2개:

  1. 저는 아직 1404 쓰는 중인데, systemd라는게 그냥 일반유저 입장에선 특정 프로세스 (실행 중 프로그램의) cpu 할당 점유율 퍼센트를 유저가 직접 제한할 수 있고, 또 부팅 속도가 느껴질랑 말랑 정도로 빨라지는 차이 외엔 특별한 변화는 없는 거지요?

    답글삭제
  2. 리눅스 서버 사용자라면 systemd에 대해 좀 알아야겠지만, 데스크탑 사용자라면 달라진걸 거의 못느낄 거예요. cpu 점유율하고 관련이 있긴 한데 Windows 서비스 관리자처럼 리눅스 시작 프로세스를 변경할 수 있는 것이죠. 사실 systemd가 하는 일은 더 많은데 이 때문에 논쟁이 벌어지기도 했었죠... 일반 사용자입장에서도 systemd를 알아야만 하는 상황이 올 수도 있긴 있겠더군요. 간혹, 부팅시간이 너무 길어지거나 시스템 종료시간이 너무 길어질때요... 대부분의 경우는 문제가 없지만요.

    답글삭제