Skills/mY Technutz 2018.03.29 13:31

결국 같은 이슈였다.

내가 전에 올렸던 Kernel Dump Analysis #14 / #15 두개의 이슈..

결국 #15 와 #14 모두 동일한 rport reference count 관련 race condition bug 였다.

비록 양상이 다르긴 했지만 모두 Kref 를 감소시키며 0 으로 만드는 과정에서

Race condition 으로 인해 다른 메모리 값을 참조하게 되는 버그였다.

아래는 해당 버그에 대한 Patchwork (GIT) 링크 이다.

https://patchwork.kernel.org/patch/9132823/

대략 reference count초기화 하는 과정에서 Mutex lock 을 걸어

Violation 을 방지하려고 했는데, 매 타임마다 Locking 을 하고 그 값을 대기하다보니

대기시간중에 다른 스레드가 해당 구조체에 엑세스 할 기회를 만들어주게 되어

결국 해당 값이 바뀌어 버리는 일이 생길 수 있다는 것이고, ( Race condition )

이 과정을 단순히 Remote port 에 대한 참조카운트를 추가하여

해당 값을 Lookup 할때 (디스크 제거시에만) 참조값을 줄이면 되기 때문에

디스크를 제거/검색 하는 과정에서 매번 디스크 뮤텍스를 걸 필요가 없게 수정한 이다.

개 빡치는것은, 내가 분명 두가지 모두 최종 Call trace 는 다르지만 모두 libfc 모듈에서

fc_lport / fc_rport 관련 구조체에 대한 Referencing 에서 나오는 이슈이므로

동일한 것같다고 이야기 했지만,

커널 개발팀에서 계속 "아니다, 다르다, 재현해서 다시 살펴봐야 한다" 라고 우기는 바람에

고객이 너무 빡쳐서 "그냥 다 때려쳐 씨밤, 너네 구려!" 이랬다는 것...

졸라 중요고객이라고 지랄들을 해대서,

어떻게 해야 할지 몰라 냅뒀더니 두달이 지난 지금에서야

We are unable to reproduce the crash in QA setup which is often hard to do because it is not possible to replicate customer environment in the lab.
However, The two core dumps even though showed different symptoms, but the underlying root cause is the same, the kref count being zero. 

Rajan provided the Ksplice patch and rpms which has the fix to address kref handling.

'응 그래, 재현이 졸라 안되서 미안하지만...그래도 동일 이슈맞는것 같아

우린 이미 앞선 패치를 통해 솔루션을 제공했어. 우린 잘했다고'

이지랄을 떨고 있다.

개발자들 일안하냐? 내가 호구로 보이냐? ㅎㅎㅎㅎㅎ 아몰랑!


'Skills > mY Technutz' 카테고리의 다른 글

kernel Dump Analysis #18  (1) 2019.05.11
Kernel Dump Analysis #17  (0) 2019.04.04
libfc: Update rport reference counting bug - 1368175  (0) 2018.03.29
Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
Kernel Dump Analysis #14  (0) 2018.02.13
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018.02.22 13:27

와.. 대박... 일이 엄청나게 들어와..

공격적으로 오라클 리눅스를 장사하면 내가 쓰일만한 일이 있긴 하구나 하면서도

일이 이렇게 많아지면 개빡쳐서 아무것도 하기 싫어지는 현자타임같은게 온다는..

무튼, 요즘 핫하게 밀려들어오는 업무량 덕에 코어분석 일도 숭풍숭풍 막 쳐 들어오는..

이번에는 레드햇 커널 즉, Oracle Linux 에서 Cmompatibility 를 위해 제공하는

Redhat Compatible Kernel ( RHCK ) 와 관련된 커널 덤프 분석을 해주시겠다.

Technical Preview 이기 때문에 해당 부분에 대한 코드는

ASSERTCMP(op->state, ==, FSCACHE_OP_ST_DEAD);

로 수정되는 식으로 상황을 정리하는 코드가 추가된 것 같다.
( 수정된 코드 다운받거나 찾기 귀찮다! 바쁘다. 점심안에 써야한다 글을. )

물론 픽스는 해당 fscache 모듈을 사용하지 않도록 하거나,

( cachefilesd 데몬을 Disable 한다. )

ELSA-2017-0307 또는 ELSA-2017-0817 ( RHSA-2017-0817 대응) 에서 권고하는

kernel-2.6.32-696.el6 이후의 최신 버젼으로 업그레이드 하거나

6.8 GA kernel-2.6.32-642.el6 이하 커널로 다운그레이드 하면 된다고

Redhat 에서 이야기 하는 것 같다.

사실 개인생각으로는 커널 업그레이드를 해봤자 동일할것 같긴 해서

구지 필요하지 않다면 Cachefilesd 를 Off 하는게 더 좋을것 같다고 생각된다.

mount option 에서 fsc 가 생겼는데 이게 없으면 자동으로 fscache 가 활성화 된다고 하는 것 같다.

레드햇 이슈라 명확하게 솔루션 코드가 확인되지 않는 상태라 잘 모르겠으나

분석 방법이랑 워크어라운드 기입되 있음 이미 난 충분히 세계를 위해 기여한거시다...

'Skills > mY Technutz' 카테고리의 다른 글

Kernel Dump Analysis #17  (0) 2019.04.04
libfc: Update rport reference counting bug - 1368175  (0) 2018.03.29
Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
Kernel Dump Analysis #14  (0) 2018.02.13
Kernel Crash dump Analysis - #13  (0) 2017.12.20
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018.02.19 13:18

저번 14 에 이어진 내용이라고 볼 수 있다.

지난시간 왜 시스템 커널 분석에서 fc_stat, fc_lport 에 집중했는지 나오는 부분이다.

이전 게시글에서와 동일하게 ffff880103e67a00  를 참조하는 부분에서 문제가 발생하였다.

따라서 fc_lport 에 관련되어 메모리를 사용함에 있어, 이미 해제된 메모리를 재참조하거나,

메모리 corruption 조건이 발생되고 있다는 것을 의미한다.

역시 저번 게시글과 같이 해당 코드에 논리적 오류나 Race condition 발생 여부,

Used-after-freed 현상에 대해서 더 살펴봐야 하는 상태이지만,

코드 상 특별히 문제될만한 부분은 발견되지 않았다는 점이 현 문제의 가장 큰 난관이다.

지금은 개발팀에서 in-house 로 동일 환경을 구성 후 재현테스트를 하고 있는 중이다.

이는 장비에 대한 특성 ( 펌웨어 문제 또는 하드웨어 관련 된 정보의 괴리 ),

즉 하드웨어 문제를 배제할 수 없는 의심스러운 부분이 있다는 것을 의미한다.



posted by mirr

댓글을 달아 주세요

Skills/System 2017.04.03 17:44

흥미있는 버그를 발견했다.. 물론 알려진 버그인데,

분석하는 과정을 개인적으로 업데이트하고 공유한다.

이슈는 엑사데이타에서 사용하는 UEK2 (2.6.39-400.264.1) 커널의 crash 이다.

이는 사실상 Async/Direct IO 상태로 사용시 ext4 의 io end 처리 구조체 및 펑션에서

더블프리가 될 수 있는 버그로 알려져있으며 패치가 나와있다.

Fixed -> UEK2 2.6.39-400.277.1


posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2017.01.08 13:38


원문 : https://lwn.net/Articles/710545/

이번주 LWN 에서 내가 흥미로와 하는 내용중 하나인 메모리 관련 기사가 올라와 번역해 본다.


----

즉, 기존의 빠른 발전을 위해 여러가지 추가해 왔던 메모리 관리 관련 기능들을 예로 들면서,

25년이 넘은 만큼, 리눅스 개발 전반적으로 "더 나은 진화를 위한 한발 물러섬"

에 대한 내면적 리뷰가 필요한 시점임을 전달하고 싶었던 것이 아닐 까 싶다.

자세한 내용은 다음주 수요일 이후 공개가 되니 직접 살펴보기 바란다.

근데 이렇게 이야기 해주면 다들 알긴 아나? 좀 회의가 들어 요즘 -_-


posted by mirr

댓글을 달아 주세요

Skills/System 2016.12.01 11:06

KSpliceOracle 에서 인수한 Live patching 솔루션이다.

현재 RHEL 의 Kpatch 나 Suse 의 KGraf 가 비슷한 역할을 하고 있지만,

오라클에서 KSPlice 를 인수함으로 인해 대체된 프로젝트들이고,

단연 KSplice 의 기능이나 편의성이 더 뛰어난 상태이다.

일전에 LWN 기사 중 Kernel Live patching 에 대한 번역글을 포스팅 했었는데,

기사중, Micro-conference 중 User-space Bootless patch 에 대한 문의가 있었고,

커널개발자들이기 때문에 모두들 그 부분을 무시하고 넘어갔었다고 전한 적 있다.

오라클은 2015년 부터 KSplice 의 User-Space Bootless patching 을 준비해 왔고,

2015년 Oracle Announce utube 에서 Larry Alison 회장의 소개가 진행된 적 있다.

User-space 패치 가능한 영역은, 물론, 보안에 관련된 패키지들에 한정된다.

어플리케이션 레벨은 패치 후 리부팅하면 그만이지 않나? 라고 생각하기 쉽지만,

의외로 많은 크고작은 기업들의 시스템 엔지니어들은 이 부분에 대해서

많은 머리숱이 고난을 받았었음을 기억해야 한다.

"네, 당신들이 신경안쓰고 있던 부분... 오라클이 합니다."

PS : 그래.. 광고성 성향이 강하고 오라클 빠돌이같은 느낌이 있지만,
     그렇다고 오라클 리눅스 쓰라는거 아냐..쓰지마, 안써도 돼...
     지금 고객들만으로도 난 충분하고 귀찮어... 더 안늘어나도 돼...
     일하기 싫단말야... 고객들따위는 개에게나 줘버................ 아, 내가 "개" 지 ㅠㅠ

posted by mirr

댓글을 달아 주세요

Skills/Drill or Guard 2016.10.06 22:15

오랜만에 올리는 글,


https://fossbytes.com/this-single-line-of-code-can-crash-a-linux-system/


현재 위와 같은 systemd 관련 서비스 거부 취약점이 발견되면서

다소 두려워 하는 관리자들도 있을 것이라고 생각하여 대처방안을 생각해 보았다.


사실 대처방안이라고 하기에도 그렇고,  단순한 Workaround 가 아닐지도  모르고

어차피 패치된 버젼 나오면 그 패키지를 사용하면 되지만,


언제 나올지 모를(금방 나올테지만)  패치,  그리고 리부팅이 필요할 것으로 보이므로

리부팅이 부담되는 사람을 위한 꼼수를 생각해 내었다.


(원래 어제 하도 난리일때 기사도 제대로 안보고 있다가 오늘 퇴근하고 집에오면서 생각좀 해봄)


1. NOTIFY_SOCKET 을 세팅하는 과정에 시스템은 어떤  감사가 이루어 질까?


-  해당 내용을 확인하기 위해 우선 audit 설정을 해주었다.


# auditctl -w /usr/bin/systemd-notify -p x -k systemd_notify


위 설정은 systemd-notify 가 수행되면 systemd_notify 라는 라벨(키워드)  로

audit log 를 남기도록 설정한 룰이다.


간단히 테스트 해보자.


#  NOTIFY_SOCKET=/run/systemd/notify systemd-notify "test"

# ausearch -i -k systemd_notify

type=PATH msg=audit(10/06/16 08:02:05.657:79) : item=1 name=(null) inode=379981 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=s
ystem_u:object_r:ld_so_t:s0
type=PATH msg=audit(10/06/16 08:02:05.657:79) : item=0 name=/usr/bin/systemd-notify inode=325712 dev=00:1d mode=file,755 ouid=root ogid=root
 rdev=00:00 obj=system_u:object_r:systemd_notify_exec_t:s0
type=CWD msg=audit(10/06/16 08:02:05.657:79) :  cwd=/root
type=EXECVE msg=audit(10/06/16 08:02:05.657:79) : argc=2 a0=systemd-notify a1=test                <<<<<<
type=SYSCALL msg=audit(10/06/16 08:02:05.657:79) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x2491450 a1=0x232cfe0 a2=0x246f850 a3=0
x7ffde71a9e40 items=2 ppid=4535 pid=5743 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=6 tty
=pts1 comm=systemd-notify exe=/usr/bin/systemd-notify subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=systemd_notify


여기서 execve 타입에서 해당 Argument 가 나오는게 확인되었다.


자,  그럼 일단 감사시스템은 구축했으니,  그냥 누가 이거 실행하면 조지면 되는건가?


하지만 이미 시스템은 망가진 뒤  일텐데?


2.  기존 systemd-notify 를 대체할 만한 방법이 없을까?

-  이 아이디어를 바탕으로 고민해보다가 누구나 간단히 사용 할 수 있을 만한

Bash scripts 를 이용한 커맨드 대체 를 생각했다.


#!/bin/bash

if [ -n $NOTIFY_SOCKET ]
then
    systemd-notify_org $1
fi


그래,  문제의 원인은 NOTIFY_SOCKET 이라는 환경변수의 사용이며,

notify 프로그램 뒤에 Argument 를 넣지 않았다는 것이 핵심이었다.


따라서,  이를 체크하여 만약 해당 내용이 Null 이 아니라면

( 나의 테스트로는 Redhat 계열에선 기본 Null 인거같다 -  레댓계열밖에 몰라!)

해당 변수를 먼저 해제하거나 그냥 해당 내용을 echo 로 뿌려주면 될 것 이다.


만약 해당 변수가 아무것도 없다면,  혹은 정상적으로 사용된 것이라면

원래 있던 이름이 바뀐 systemd-notify 를  실행시켜주면  아무 문제 없이 수행 될 것이다.


테스트 해 보았다.


[root@perftest ~]# NOTIFY_SOCKET=/run/systemd/notify systemd-notify "test"
[root@perftest ~]# NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
systemd-notify_org [OPTIONS...] [VARIABLE=VALUE...]

Notify the init system about service status updates.

  -h --help            Show this help
     --version         Show package version
     --ready           Inform the init system about service start-up completion
     --pid[=PID]       Set main pid of daemon
     --status=TEXT     Set status text
     --booted          Check if the system was booted up with systemd
     --readahead=ACTION Controls read-ahead operations
[root@perftest ~]# echo $NOTIFY_SOCKET

[root@perftest ~]#


Audit 내용은 아래와 같다.


type=PATH msg=audit(10/06/16 09:05:33.533:199) : item=2 name=(null) inode=379981 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0
type=PATH msg=audit(10/06/16 09:05:33.533:199) : item=1 name=(null) inode=6081 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shell_exec_t:s0
type=PATH msg=audit(10/06/16 09:05:33.533:199) : item=0 name=/usr/bin/systemd-notify inode=437427 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:systemd_notify_exec_t:s0
type=CWD msg=audit(10/06/16 09:05:33.533:199) :  cwd=/root
type=EXECVE msg=audit(10/06/16 09:05:33.533:199) : argc=2 a0=/bin/bash a1=/usr/bin/systemd-notify         <<<<<
type=EXECVE msg=audit(10/06/16 09:05:33.533:199) : argc=3 a0=/bin/bash a1=/usr/bin/systemd-notify a2=test
type=SYSCALL msg=audit(10/06/16 09:05:33.533:199) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x1af3c00 a1=0x1b44a40 a2=0x1b28870 a3=0x7ffc2e391ca0 items=3 ppid=2191 pid=7914 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=1 tty=pts0 comm=systemd-notify exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=systemd_notify
----
type=PATH msg=audit(10/06/16 09:05:36.597:200) : item=2 name=(null) inode=379981 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0
type=PATH msg=audit(10/06/16 09:05:36.597:200) : item=1 name=(null) inode=6081 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shell_exec_t:s0
type=PATH msg=audit(10/06/16 09:05:36.597:200) : item=0 name=/usr/bin/systemd-notify inode=437427 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:systemd_notify_exec_t:s0
type=CWD msg=audit(10/06/16 09:05:36.597:200) :  cwd=/root
type=EXECVE msg=audit(10/06/16 09:05:36.597:200) : argc=2 a0=/bin/bash a1=/usr/bin/systemd-notify
type=EXECVE msg=audit(10/06/16 09:05:36.597:200) : argc=3 a0=/bin/bash a1=/usr/bin/systemd-notify

type=SYSCALL msg=audit(10/06/16 09:05:36.597:200) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x1b45a20 a1=0x1abb040 a2=0x1b28870 a3=0x7ffc2e391ca0 items=3 ppid=2191 pid=7916 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=1 tty=pts0 comm=systemd-notify exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=systemd_notify


사실 -z 를 넣어야 하는게 맞나?  싶었는데 테스트 해본결과 -n 로 넣어 놓는게 훨씬 무탈하고 자연스러워

해당 내용을  유지하기로 했다.


각자 script 및 원본 명령 위치등은 알아서 수정하면 될거같다.  보안적으로.


간단한 테스트만 하고 올린 글이라 각자 상황에 맞게 이런 컨셉으로 보완해 사용하시길.


아주 간단히 테스트만 한두시간 해보고 올리는 글이니 문제가 된다면 삭제할 예정

(나에게 책임이란 없다.)


끝.

posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply Favicon of https://seblog.mirr4u.com BlogIcon mirr

    심심해서 몇번 테스트 해본 결과 위와같이 스크립트를 통하게해서 직접적으로 /run/systemd/notify 라는 소켓파일에 Null 인자로 write access 하는 부분만 막으면 큰 문제 없는 것 같다..
    어차피 패치 나올것이므로 간단하게만 테스트 한거니, 컨셉만 생각해서 적용하면 될거같다...

    2016.10.07 00:00 신고

Skills/mY Technutz 2016.01.14 23:08

정말 백만년만의 글인가.... 하고 보니 작년 6월에 글 썼었네... ㅎ


일년에 두개정도면 많은거 같은데..


무튼 어느순간 일이 증가하고, 같이 일하는 사람들이 생겼다 없어졌다 다시 생기는 등


신경써야 할 것들이 많았던 터라 영 공부를 할 수 없었는데,


최근 회사 엔지니어들이 주고받는 메일링 리스트를 보고 다시 이쪽저쪽 들쑤시려고 하는 중...


메일링 리스트에 고객이 많은 메모리를 쓰고 있고, 어떤 이슈가 생겨서, kdump 설정을 통해 덤프를 떠


분석하려고 하는데 이게 자꾸 설정이 안된다는 것이다..


답변으로 오는 것들은 대부분 이것저것 crashkernel 값을 조절해 보라 정도...


그래서 살펴보았다 어떤 공식을 통해 해당 영역이 Allocation 되는지를 말이다.




여기서 내 결론은 일반적으로 crash kernel 은 전체 메모리를 완벽하게 다 뜬다고 볼 수 없으며,


Kernel 에 대한 영역을 위주로 커널이 갖고 있는 PTE 등의 Linked List 정보를 덤프한다고 볼 수 있으므로,.


물리적 메모리 양이 많이 있다고 해서 crashkernel 을 무턱대고 올리는 것이 아니라,


2G - 256M 를 기준으로  64M 씩 올려가면서 테스트 해야 한다는 것이다...


참고로 레드햇 기준으로는 2G-256M, 6G - 512M, 8G - 768M, 그 이상이어도 869M 넘지 않도록


권고하고 있다... ( 난 8G - 768 M 도 too much 하다고 본다.. )


이슈에 대한 추이가 기대되는 부분이다...














posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply BlogIcon k

    최대...768m...그정도면..1tb 메모리도이상없는듯...
    메모리보다는....장착되어있는..디바이스에 따라 차이를 보이는듯하네요...물론..메모리도 상관 있는듯...

    2016.01.15 18:56
    •  Addr  Edit/Del Favicon of https://seblog.mirr4u.com BlogIcon mirr

      드라이버 등에 영향을 받을 수 는 있죠, 문제는 100테라 넘는 애들에 대한 문제인데, 이부분에선 사실 글에서 언급하지 않은 copy_to_user 의 개선이필요하다고 보는거죠 이부분에서 memcpy 부분의 효율 개선이나 다른 방식의 improve 가 필요하다고 봐요.. OOM 이 발생했다는게 이슈니까요 ㅎㅎ

      2016.01.16 00:14 신고
  2.  Addr  Edit/Del  Reply BlogIcon k

    최대...768m...그정도면..1tb 메모리도이상없는듯...
    메모리보다는....장착되어있는..디바이스에 따라 차이를 보이는듯하네요...물론..메모리도 상관 있는듯...

    2016.01.15 18:56
  3.  Addr  Edit/Del  Reply Favicon of http://seblog.mirr4u.com BlogIcon 미르

    낚임.. 결국 800M 로 덤프 성공.. OOM 부분은 역시 각종 모듈이 영향을 준 것이긴 한데, kdump 에선 이를 위해 blacklist 라는 옵션을 kdump.conf 레벨에서 제공..
    이를 다 블랙리스트로 처리하고 dump 를 뜨면 충분히 떠진다는 점....

    2016.01.18 15:20

Skills/System 2015.06.20 20:03

하도 짜증나서 쓰는 글이다.


SR 로 매번 열리는 것도 한계가 있고, 그런 반복되는 SR 따윈 하고싶지 않기에,


글로벌 굴지의 S 모그룹사에서 무한대로 쓰잘대기없이 파고드는 질문만 하는거


답변하기도 귀찮아서 글을 작성..


뭐 있든지 없든지 모르겠지만 일단 검색해도 잘 모르겠으니까 다들 물어보는거 아닐까?


Leap second ( 윤초 ) 라는 것은 일단 모든 시계는 사실상 아주 정확하게 기록되지 않는 다는 것을 기본 전제로,


원자시계와 현실시계가 1초이상 차이가 나게 될 경우, 그 1초를 더하거나 빼주어 보정하는 것을 의미한다.


올해 즉 2015년 6월 30일 (우리나라는 7월 1일) 에 발생하며, 양의 윤초다.


양의윤초는 뭥미? 에 대해서는 아래 나온다.


윤초시의 시간보정은 양의 윤초(+), 음의 윤초로(-) 나뉘어 지며 아래와 같다.


<양의윤초>

08:59:59.00201

08:59:59.20329

08:59.59.58291

08:59:59.89201

08:59:60.20392            <<<<< 60 초 라는 가상의 초가 삽입된다.

08:59.60.74829             <<<<<

09:00:00 


<음의윤초>

08:59:59.00201

08:59:59.20329

08:59.59.58291

08:59:59.89201

08:59:59.10392            <<<<< 59 초 가 다시 반복된다.

08:59.59.74829             <<<<<

09:00:00 


올해의 시간보정은 양의윤초의 타임테이블을 따르며, 시스템은 저렇게 시간을 표시하게 된다.


그럼 이 윤초는 단순한 시간보정인데 뭐가 이렇게 난리이냐?


이 윤초 적용을 통해 시간테이블이 늘어나면서 (쉽게 설명하자면) 커널 및 어플리케이션 일부의 Timer가


오동작하는 것이 실제 문제이다. 즉 Leap second effect 라고 하며, 두가지로 나뉠 수 있다.


바로 스템 전체에 가져오는 문제와 어플리케이션끼리의 시간동기화 실패 문제이다.


1. 커널의 경우 Jitters 라는 커널 timer 가 값을 잘못 갖게 되면서


Panic 또는 Rebooting 을 발생시킬 수 있다.


아래는 윤초 보정이 대비되지 않아 커널 Freezing 등을 발생시킬 수 있는 커널을 나열하였다 :

RHEL4/OL4 : 2.6.9-89 이전

RHEL5/OL5 : 2.6.18-164 이전

RHEL6/OL6 : 2.6.32-279.5.2 이전


즉 자신의 시스템이 해당되는 커널 보다 낮은 버젼을 사용하고 있다면,


100% 확률로 윤초 보정으로 인한 Freeze 또는 리부팅이 발생할 수 있다는 것이다.


이 사태를 해결하기 위해서는 각 플랫폼(OS version) 별로,


기술된 커널 버젼 이상의 버젼으로  업그레이드 해야 한다.


2. 두번째 문제인 어플리케이션의 시간이 동일하게 동작해야만 하는 서비스 차원의 문제이다.


이런 경우 NTP daemon 을 통해 우리는 시스템의 시간을 동기화 하고 있다.


다만 이 NTP 의 시간동기화 방식에는 절대적인 값을 그대로 Counting 하는 방법과,


NTP server 가 되는 동기화 대상 서버의 Timer 와의 시간을 1000 (또는 500) PPM 범위 안에서


Offset 기반으로 유지시켜 동기화를 시키는 방법인데,


Leap second 의 해결을 위해서는 Offset 기반으로 하는 SLEW 모드를 사용하여 NTP 를 동작시켜야 한다.


방법은 다음과 같다 (RHEL/OL 기준):


# vi /etc/sysconfig/ntpd

OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"         <<<  -x option 추가.

# service ntpd restart


간단하게 이렇게 Slew 모드를 사용해 동작시키면 윤초 보정에 대한 걱정을 하지 않아도 된다.


하지만 RHEL6/OL6 의  ntp-4.2.6p5-1, ntp-4.2.6p5-2 버전을 사용시에는


Slew mode 로 동작하지 않는 버그가 있으므로, 그 이상의 NTP package 로 업데이트가 필요하다.


3. NTP 를 사용하지 않는 서버들의 경우에는 TZdata 라는 Timezone data 테이블을 업데이트 해주면 된다.


tzdata 라는 패키지를 통해 우리는 다른 모든 국가의 나라들을 쉽게 알 수 있고, 설정할 수 있다.


leapsecond 보정이 반영된 tzdata 의 버젼은 아래와 같다 :

tzdata-2015a-1


정리하자면, Leap second 보정으로 인해 발생할 수 있는 문제는 두가지로써,


커널의 Panic, Rebooting 과 어플리케이션들의 시간이 동기화되지 않는 문제이다.


1. 커널의 경우는 아래 조건들 이상의 커널로 업데이트가 필요하다 :

RHEL4/OL4 : 2.6.9-89 이상

RHEL5/OL5 : 2.6.18-164 이상

RHEL6/OL6 : 2.6.32-279.5.2 이상


2. NTP 를 사용하는 시스템의 경우 Slew mode 로 수행해야 하며,


ntpd daemon 을 -x 옵션과 함께 실행하면 해결된다.


다만 RHEL/OL 6 버젼에서 제공되는 ntp-4.2.6p5-1, ntp-4.2.6p5-2 이 두 버젼에서는


Slew mode 가 동작하지 않는 버그가 있으니 그 이상의 NTP 패키지로 업그레이드 한다.


3. NTP 를 사용하지 않는 시스템의 경우, tzdatatzdata-2015a-1 이 후로 업그레이드 한다.


참고로 다음 표를 살펴 시스템에 대조해 보면 Leap seccond issue 에 Affected 된 시스템인지 쉽게 알 수 있다.


 

 Kernel

 NTP 사용

 NTP 사용 안함

 RHEL/OL 4

 2,6,9-89 이하

-x 옵션 없음

 tzdata-2015a-1 이하

 RHEL/OL 5

 2.6.18-164 이하

-x 옵션 없음

 tzdata-2015a-1 이하

 RHEL/OL 6

 2.6.32-279.5.2 이하

ntp-4.2.6p5-1

ntp-4.2.6p5-2

 tzdata-2015a-1 이하

 RHEL/OL 7

 해당없음

-x 옵션 없음

 tzdata-2015a-1 이하

 UEK 사용시

 해당없음

-x 옵션 없음

 tzdata-2015a-1 이하






posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply mangrove

    음의 윤초 틀렸어요.

    58초에서 바로 00으로 넘어가는 것이 음의 윤초에요.

    https://en.wikipedia.org/wiki/Leap_second

    2016.10.28 14:41
    •  Addr  Edit/Del Favicon of https://seblog.mirr4u.com BlogIcon mirr

      네, 정의적으로는 그렇지만, 실제 tzdata 의 타임테이블을 보면 전부 삽입형싱으로 구현되었구요, 이걸 59초를 넣는지 60초 이후 한테이블을 더 넣는지 로 구분해서 구현되었더라구여.. 실제 데이타를 바탕으로 이어기 한거에요...

      2016.10.28 19:10 신고

Skills/mY Technutz 2014.06.18 16:30

레드햇보다 발빠르게 패치되어 제공되는 EgyptRamadan 기간을 위한 Timezone 정보 패키지!! 

Redhat bugzilla 에서 발견되고 있지 않다..사전에 지인을 통해 확인해 보았으나, 역시나 최신데이타에서는 패치버젼이 제공되지 않는...


해당내용인 즉슨, Egypt/Cairo 에서는 "The Muslim of Ramadan" ,

라마단 기간동안 DST ( Daylight Saving Time) 적용을 해제하도록 되어 있고,

이것은 6월 26일 부터 적용하기로 Government announce 가 되었는데,

tzdata 를 통해 본 데이타로는, 잘못 되어 있었다는 것이지...


현재 오라클 리눅스 최신패키지

OL5 : tzdata-java-2014d-1.el5,

OL6 : tzdata-2014b-3.24.el6.noarch 


위 패키지들에서 본 zdump 데이타는 아래와 같다 :


zdump -v /usr/share/zoneinfo/Egypt  | grep 2014

/usr/share/zoneinfo/Egypt  Thu May 15 21:59:59 2014 UTC = Thu May 15 23:59:59 2014 EET isdst=0 gmtoff=7200
/usr/share/zoneinfo/Egypt  Thu May 15 22:00:00 2014 UTC = Fri May 16 01:00:00 2014 EEST isdst=1 gmtoff=10800
/usr/share/zoneinfo/Egypt  Sat Jun 28 21:59:59 2014 UTC = Sun Jun 29 00:59:59 2014 EEST isdst=1 gmtoff=10800
/usr/share/zoneinfo/Egypt  Sat Jun 28 22:00:00 2014 UTC = Sun Jun 29 00:00:00 2014 EET isdst=0 gmtoff=7200
/usr/share/zoneinfo/Egypt  Mon Jul 28 21:59:59 2014 UTC = Mon Jul 28 23:59:59 2014 EET isdst=0 gmtoff=7200
/usr/share/zoneinfo/Egypt  Mon Jul 28 22:00:00 2014 UTC = Tue Jul 29 01:00:00 2014 EEST isdst=1 gmtoff=10800
/usr/share/zoneinfo/Egypt  Thu Sep 25 20:59:59 2014 UTC = Thu Sep 25 23:59:59 2014 EEST isdst=1 gmtoff=10800
/usr/share/zoneinfo/Egypt  Thu Sep 25 21:00:00 2014 UTC = Thu Sep 25 23:00:00 2014 EET isdst=0 gmtoff=7200


이는 현재 최신버젼인 Redhat Linux 와 동일한 버젼이며, 데이타 역시 동일하다.


Oracle 에서는 어제 ( 6/17일 2014 ) 부로 Egypt Exadata 팀으로 부터 

Priority 1 Urgent 로 버그가 오픈되어, 현재 Fixed 버젼이 나왔으나, QA 중이다.

( tzdata-2014b-1.0.1.el5 )


zdump 로 보았을때 정확하게 수정된 정보는 다음과 같다 :

# zdump -v /usr/share/zoneinfo/Egypt  | grep 2014

/usr/share/zoneinfo/Egypt  Thu May 15 21:59:59 2014 UTC = Thu May 15 23:59:59 2014 EET isdst=0 gmtoff=7200

/usr/share/zoneinfo/Egypt  Thu May 15 22:00:00 2014 UTC = Fri May 16 01:00:00 2014 EEST isdst=1 gmtoff=10800

/usr/share/zoneinfo/Egypt  Thu Jun 26 20:59:59 2014 UTC = Thu Jun 26 23:59:59 2014 EEST isdst=1 gmtoff=10800

/usr/share/zoneinfo/Egypt  Thu Jun 26 21:00:00 2014 UTC = Thu Jun 26 23:00:00 2014 EET isdst=0 gmtoff=7200

/usr/share/zoneinfo/Egypt  Thu Jul 31 21:59:59 2014 UTC = Thu Jul 31 23:59:59 2014 EET isdst=0 gmtoff=7200

/usr/share/zoneinfo/Egypt  Thu Jul 31 22:00:00 2014 UTC = Fri Aug  1 01:00:00 2014 EEST isdst=1 gmtoff=10800

/usr/share/zoneinfo/Egypt  Thu Sep 25 20:59:59 2014 UTC = Thu Sep 25 23:59:59 2014 EEST isdst=1 gmtoff=10800

/usr/share/zoneinfo/Egypt  Thu Sep 25 21:00:00 2014 UTC = Thu Sep 25 23:00:00 2014 EET isdst=0 gmtoff=7200


우리 Joe Jin 이 수정한 패치이다.


이집트... 폭동도 많고 내전에, 테러에 말도 많은 나라지만...


좀 신경좀 써주자 -_-..


posted by mirr

댓글을 달아 주세요