리눅스판 Y2K, 고쳐지나

리눅스 커널 5.6 버전에서 32비트 '에포크타임' 문제 해결

리눅스의 Y2K인 '에포크타임(Epoch Time)' 문제를 해결하려는 오픈소스 SW 진영의 움직임이 빨라지고 있다. 32비트 기반 리눅스가 그리니치표준시로 2038년 1월19일 새벽 3시14분8초까지만 시간을 표현할 수 있는 문제인데, 올해 처음으로 관련 문제를 해결한 리눅스 커널이 나온다.

13일(현지시간) 미국 지디넷에 따르면, 리눅스 커널 개발자 안트 베르크만을 비롯한 여러 개발자가 곧 배포될 '리눅스 5.6' 커널에서 해당문제를 해결하겠다고 밝혔다.

리눅스, 맥OS, 포식스(POSIX) 등 유닉스 계열 운영체제는 1970년 1월1일 0시0분0초부터 1초 단위 정수로 시간을 늘려가며 표시한다. 32비트 체계에서 표현 가능한 시간은 21억4천748만3천647초이며, 그 마지막 시간이 2038년 1월19일 새벽이다. 표현할 수 있는 시간이후부터 32비트 유닉스계열 OS를 사용하는 시스템은 오버플로 현상을 일으켜 심각한 문제를 초래할 수 있다.

안트 베르크만은 "리눅스 5.6이나 5.4 백포트(backport) 패치는 32비트 시스템을 2038년 이후에도 구동되게 설계된 첫번째 발표여야 한다"고 강조했다.

모든 유저스페이스는 64비트 'time_t'로 컴파일돼야 한다. 리눅스 5.6 커널과 함께 나올 'musl-1.2'와 'glibc-2.32'를 지원해야 하기 때문이다.

시스템콜 인터페이스를 사용하는 애플리케이션은 'time64 syscall'을 사용하도록 해야 한다. 이는 리눅스 5.1에 추가된 것이다.

커널 uapi 헤더 파일이나 기타 콘텐츠의 개인키를 사용하는 애플리케이션은 리눅스 5.6 버전으로 업데이트해야 한다.

일부 인터페이스는 64비트 'time_t'로 변경될 수 없다. 때문에 'CLOCK_MONOTONIC' 시간을 사용하도록 구성돼야 한다.

64비트 기기에 나타나는 모든 에포크타임 문제는 32비트 시스템에도 적용된다. 32비트초 표시를 사용한 타임스탬프를 기록하는 파일시스템이 특히 영향을 받는다. 확장파일시스템 중 ext3 형식 소형 아이노드를 사용하는 ext4, ext2, xgfs, ufs 등이 해당된다.

에포크타임 문제의 핵심부분이 고쳐져도 해결해야 할 작업은 많다.

맥OS는 10년 넘게 32비트 SW 퇴출 노력을 해왔다. 그러나 작년 나온 맥OS 카탈리나가 처음으로 32비트 앱을 완전히 퇴출한 버전이다. 그만큼 32비트에서 64비트로 넘어가는 작업이 더디게 진행된다는 것이다.

오늘날 리눅스를 비롯한 대부분의 OS가 64비트로 전환되고 있다. 때문에 32비트 리눅스의 에포크타임 문제가 예상보다 심각하지 않을 수 있긴 하다.

미국 지디넷의 스티븐 J. 보간니콜스는 "오늘날 구동되는 컴퓨터는 모두 64비트인데, (에포크타임이) 왜 문제인지 의아할 수 있다"며 "많은 임베디드 시스템과 사물인터넷(IoT) 기기는 여전히 32비트 OS"라고 설명했다.

그는 "확실히 2038년까지도 새로운 32비트 기기가 시장에 출시될 것"이라며 "2020년에 다시 Y2K 버그가 부각되는 덕분에 18년 뒤에도 여전히 살아서 잘 작동하고 에포크 문제를 일으킬 시스템이 쓰레기장에 버려질 것"이라고 덧붙엿다.