남위례역. 역명이 다소 생소했습니다.
남위례역 옆의 도로를 지나다, '어, 여기에 역이 있었나'로 생각하게 합니다.
남위례역은 지상역이고, 도로위의 육교를 통해 역에 갑니다.
21년 12월에 개통되었고, 그 전에는 산성역에서 복정역이 꽤 긴 구간(2.7km)이었다고 합니다.
산성역 기준으로 왼쪽 역은 이전에는 복정역이었는데, 남위례역으로 바뀌었네요.( 아래 사진 )
24년 6월 현재, 별내선으로 연장 운행을 시범 운영하고 있습니다.
인근 역인 남위례역에서
수평으로 멏 백미터 온 것 같은데,
산성역 지하 3층 승강장 플랫폼이다.
이제 지상까지는 한참을 올라가야 한다.
첫번째 에스컬레이트이다.
두번째 에스컬레이트이다.
깊고 긴데 속도는 느리다. 스웨덴 대비.
지하철 타러 갈 때도 물론 깊겠죠.
이 역의 특징은 지하철 오는 정보를 모니터에 출력하지 않는 것 같습니다.
지하철 들어오는 것보고, 뛰다 보면 사고가 나기 쉬워서, 예방 조차 중의 하나 인 듯 합니다.
1990년 8월 1일에
대한항공 : 서울->홍콩,
에어차이나 : 홍콩->북경
의 탑승권이다.
대한항공 탐승권에 한글이 없다.
김포국제공항에서 출발인 듯 한데, 코드명이 'SEL' 이다
(현재는 인천공항은 ICN이고 김포공항은 KMP 인데, 서울이 있었다.^^)
에어차이나 등기증에 Seat Number 등 구체적인 정보가 없다.
JVM(Java Virtual Machine)이 비정상동작하였을 때, 죽으면서 그 원인을 기록하는 것입니다.
죽으면서까지 어떤 기록을 남기는 기술을 hs (hot spot)으로 칭하면서 파일 이름이 hs_err 를 포함하는 것 같습니다.
1. 언제 생성시키나?
예를 들면, 메모리 부족할 때 메모리를 할당하고자 할 때 처럼 일반적으로 오류가 있을 때.
즉 충분히 예측되는 예외사항(handled exception?) 때는 파일을 남긴다고 합니다.
2. 항상 발생시키는가?
그렇지 않다고 합니다. 어떤 감당하기 어려운 사항(unhandled exception)일 경우에는 파일을 남기지 않을 수 있다고 합니다.
3. 어디에 크래시(crash) 파일이 있는가?
특별한 옵션 지정을 하지 않았다면, 일반적으로 수행/실행시킨 경로에 파일이 만들어집니다.( Working directory of the process )
특별한 경우 즉, 디스크용량 부족, 권한 부족한 경우네는 /tmp 파일에 저장될 수도 있습니다.
4. 저장경로를 지정할 수 있는가?
지정할 수 있습니다. JAVA 구동 명령어에 '-XX:ErrorFile=/logs/ezdas/ezdasX/log/hs_error_pid%p.log' 을 추가한 후 구동시킵니다. 물론 지정경로에 대해 파일쓰기 권한을 부여합니다. 여기서 X는 0 또는 1의 값입니다.
5. 크래시 파일은 어떤 정보를 가지는가?
Thread, SigInfo, VM State, System Information, VM arguments, Environment Variables, CPU, Memory, vm_info, Resiter, Top of Stack, Instruction, Stack Info, pid, java frames, Dynamic libararies
6. ezDAS 서버에 왜 파일 기록이 없을까?
2번 항목에 의해, unhandled exception이 발생하였으면 기본 워킹 디렉토리(/app/exdas/ezdasX/bin/) 에 파일이 없을 수 있습니다. 여기서 X 는 0 또는 1의 값입니다.
또는, connector 서버( java.io.IOException: Too many open files ) 의 File open 후 close하지 않아서, 라이브러리 로딩 에러 발생 초래하는 경우이면, 파일을 기록하지 못할 수 있습니다.
또는 ulimit -a 로 조회하였을 때, core file size 가 0 이면 파일이 저장되지 않을 수 있습니다.
7. 파일을 기록하는 한도를 무제한으로 변경하는 조치는?
ulimit 는 프로세스의 자원 한도를 설정하는 명령입니다.
현재 설정되어져 있는 값을 조회하는 명령어는 ulimit -aH 입니다.
최대 코어 파일 사이즈를 변경하는 명령어 및 옵션은 ulimit -c unlimited 입니다.
영구적으로 저장하려면 .bashrc 나 .bash_profile에 해당 명령어를 입력하여 저장합니다.
해당 계정으로 재접속 후, 값이 제대로 변경되었는지 확인합니다. 필요시 재부팅을 필요로 할 수 있습니다.
8. 덤프파일 이외의 다른 방법으로 오류를 확인할 수 있는 방법은?
journalctl 명령어를 활용할 수 있습니다.
예를 들면,
1. 오늘 날짜 로그 보기
# journalctl --since=today
2. 특정 기간별 로그 보기
# journalctl --since "2017-05-25 00:00:00" --until "2017-05-30 10:30:00"
# journalctl --since "1 hour ago"
# journalctl --since "2 days ago"