Computer Architecture/Error

System error about docker down (1) alternatives.log

아인샴 2021. 6. 30. 09:18

도커가 다운됐다...! 학습하다가 다운되었는데 최근 전에도 이랬다. 

그래서 관련 에러를 좀만 찾아보았다.  +따로 로그드라이버를 쓰지 않았다. 

 

docker logs {container}

이 서버에서 주피터 안쓴지 꽤 됐는데 부지런히 체크하고 있었다 + 아맞다 며칠전에 사장님께 뭘 설명드린다고 씀  
하나하나 봐보자 

 * Starting OpenBSD Secure Shell server sshd                             [ OK ]

ssh 통신용 shell 열었다는 뜻 같다. (Open SSH)

더보기

OpenBSD란 오픈SSH(OpenSSH, OpenBSD Secure Shell)[a]는 시큐어 셸 (Secure Shell, SSH) 프로토콜을 이용하여 암호화된 통신 세션을 컴퓨터 네트워크에 제공하는 컴퓨터 프로그램의 모임이다 (~전략~)오픈SSH는 Tatu Ylönen에 의해 개발되었던 현재 사유 소프트웨어인 오리지널 SSH 소프트웨어의 대안으로서 OpenBSD 팀에 의해 개발되었다.

 

 

[W 2021-06-29 00:24:04.925 JupyterHub app:1695] No admin users, admin interface will be unavailable

   -관련 경고는 누군가 로그인을 시도했다가 실패한듯 하다 (일단 에러추정시간대가 이때가 아님 ) 

 8081포트를 뚫은 기억이 없는데.. 일단 킵 

일단 docker logs로는 문제발생예상시간대에 생성된 로그가 없었다. (그나마 위에 뜬 warning이 전부임) 

0. 우분투 /var/log/message에 로그가 있다고 했는데 없다. 있는것들을 열어보자 (Ubuntu 18.04)

 

1. /var/log/wtmp  #최근의 접속사항이 기록되는 파일 

해당 파일이  있길래 열어봤는데 이상했다. 

   - 그냥 vim으로 읽으면 안되고,  last -f wtmp.1 가 읽을 수 있는 형태로 출력됐다. (내용은 ip공개돼서 안함) 아무튼 wtmp를 통한 접속정보에는 다 아는 사람들뿐이었고 또 딱히 새로운 접속시간도 없었다. 최근 접속이 5/4~5/5였음 (도커밖/내부 해당)  

   1.1  /var/log/btmp도 열렸다. #로그인 시도 실패내용 기록

 

2. /var/log/lastlog :  각 사용자의 마지막 로그인 내용이 기록된 파일

   - 명령어는 없이 그냥 lastlog라고 하면 출력된다.  퇴사했던 분 접속정보가 있었다. ㅋㅋ 나중에 물어봐야겠

 

---

(07/04) 도커 내부에서  로그 보기 

개인사정은 접어둠

더보기

주말인데 회사에선 일하느라 바빠서 로그를 볼 새가 없었다. 그런데 도커 바깥의 포트는 안열고 내부 포트만 열었음으로 지금 집에서는 바깥에서 도커의 로그를 볼수가 없다. 

현재 추정하고 있는 서버다운원인은 GPU 사용으로인한 온도상승 등의 h/w 오류인데 이를 도커 내부에서 확인할 수 는 없을 것 같다. 그러나!(꼰머 모드) 원래 100%는 없어도 확인이라는 것이 50%를 99%로 만들어가는 과정이 아니겠는가

 

적어도 도커내부의 원인을 파악할 수 있는 상태에서 이를 무시할 정도로 도커 외부에 원인이 있다는 확신이 없으므로, 내부 로그를 확인하는 겸 리눅스 마스터 1급의 준비를 해보고자 한다!(TMI..)

 

1. /var/log/alternatives.log #Debian 계열 시스템에서 update-alternative의 로그

  - alternaive(update-alternative)란 심볼링 링크를 생성제거관리조회 할수 있는 기능을 제공하는 커맨드라인 툴이라고 한다. 즉, 심볼릭 링크를 통해 특정커맨드에 대해 디폴트버전 또는 기능을 정의할수 있다고 한다. (예를 들어 cuda 11버전(cuda-11.0) 10버전 깔고서도(cuda-10.0) 결국은 마지막에 /usr/local/cuda라는 심볼릭 링크로 타게팅 되어서 쓰는걸 말하나 보다) 

이건 cat으로 열렸다. (제일 만만한 cat.. 메모장 열듯이 출력한다는 명령어다. ) 

1.14일 로그라 서버다운의 원인은 아님

저 로그의 내용을 다 이해하려면 너무 오래걸릴 것 같으니 간단하게만 확인해본다. 

  • run with --install /usr/bin/automake automake /usr/bin/automake-1.15 33 \ 
    • automake 관련 순서가 있다.
    • 더보기
      dds

      - autoscan은 하위폴더를 검색해 configure.scan생성, 이 파일을 configure.ac 로 rename해서 사용한다.       - 파일변경후 configure.ac를 열어서 [] 안에 있는 변수에 value를 입력하면 된다. (rename후 edit) 

      - automake는 makefile을 만들기 위해 필요한 Makefile.in을 makefile.am을 참조해 생성한다.
      - Makefile.am은 해당 프로젝트의 정보를 기술한다. (파일이름, 하위디렉토리,소스,라이브러리등)

      - configure : autoconf로 생성한 configure을 실행한다. [명령어 : ./configure ]                                    그다음은 make(빌드 진행) > make install  (빌드 결과물로 설치) 
  • --slave /usr/bin/aclocal aclocal /usr/bin/aclocal-1.15
    • install 뒤에 나오는 것은 일반적인 경로(정확히는 link name path priority) 이고, slave뒤에나오는 것은 symbolic link의 이름이다. 정확하게는 --slave {slink} {sname} {spath} 이다.
    • 결론 : 위의 한줄은  설치를 진행하는데 있어서 /usr/bin/automake-1.15경로에서  automake라 명명하고, /usr/bin/automake에 연결한 것을 33우선순위로 설치를 진행한다.
      • slave는 추정컨데, python 을 설치할 경우 numpy나 sys 등의 내장모듈을 따로 관리하는 데 쓰는것 같다. 
  • link group automake updated to point to /usr/bin/automake-1.15
    • 이부분은 찾아도 잘 나오지 않았다. 추정컨데, 기본적으로 Automake는 {누락된} 파일의 자체복사본을 가리키는 slink를 만들려고 한다고 하여, --add-missing옵션에서 이를 활용한다. 그때 활용되기 위한 link가 이 라인이 아닌가 싶다. 

다음엔 apt폴더를 보자 

wtmp가 로그인 실패 파일인데 faillog는 무슨 실패 일꼬 저기 실마리가 있을 것인가