init
init 프로세스는 커널 부팅이 완료된 뒤 유일하게 커널에 의해 실행되는 첫번째 프로세스 = 모든 프로세스의 조상
init.d
init 프로세스가 실행되기 위한 스크립트 파일이 나뉘어 보관된 곳
/etc/rc*.d 디렉터리 파일들은 init.d 파일에 대한 심볼릭 링크
*.d 로 끝나는 디렉터리는 파일명을 순서대로 읽어서 시작 스크립트는 S, 종료 스크립트는 K 로 시작함
init의 대체
init 는 순차적으로 진행됨 = 부팅 시간이 김
유닉스 계열에서 참조하여 리눅스에서 한동안 사용되던 init 가 서비스 병렬 실행이 가능한 systemd 로 대체됨
(sbin/init -> systemd 프로그램에 대한 심볼릭 링크로 존재)
정확히는 init 와 systemd 가 공존하는 과도기랄까....?
이제 init 프로세스의 서비스는 스크립트가 아닌 systemd 유닛 중 서비스 유닛으로 제공됨 기존의 init 스크립트 실행해야 할 땐 systemd 가 이를 실행하도록 함
런레벨
OS 부팅 후 어떤 레벨로 시스템을 구동시킬지 결정함
init 런레벨 대신 systemd 에선 targets 을 사용함
*target: 특정 시스템 또는 실행 수준을 생성하기 위해 다른 장치를 함께 그룹화하는 장치 구성 파일
init 런레벨도 알아야 할 것 같아서 같이 정리함
| RunLevel | mode | 설명 | systemd | init |
|---|---|---|---|---|
| 0 | halt | 시스템 중지 | poweroff.target | init 0 |
| 1 | Single user mode | - 단일 사용자 모드 - 로그인없이 root로 로그온 - 네트워크, 서버, 파일 공유 등 서비스 사용 안함 - 시스템 점검/복구, root 계정 패스워드 초기화 등에 사용 | rescue.target | init 1 |
| 2 | Multiuser, without FS | - 네트워크를 사용X 다중 사용자 모드 - 여러 계정으로 로그온 가능 - Runlevel 3에서 네트워크 사용하지 않는 것과 동일함 | multi-user.target | init 2 |
| 3 | Full multiuser mode | 네트워크 지원하는 다중 사용자 모드 | multi-user.target | init 3 |
| 4 | unused | - 사용되지 않는 런레벨 - 사용자 정의 후 사용 가능 | multi-user.target | init 4 |
| 5 | X11 | - X Window 사용하는 다중 사용자 모드 - 그래픽 인터페이스 | graphical.target | init 5 |
| 6 | Reboot | 시스템 재시작 | reboot.target | init 6 |
/lib/systemd/system 에서 확인 가능
현재 런레벨 확인
who -r
systemd
최신 리눅스에 새롭게 도입된 시스템 관리 데몬
PID 1번을 사용하며 시스템이 부팅될 때 최초 실행되는 프로세스
*데몬: 백그라운드에서 실행되는 프로세스. 메모리에 머무르고 있으면서 특정 요청이 오면 바로 그에 대한 대응할 수 있도록 대기 중인 프로세스
systemd 유닛
systemd 에서 유닛 단위로 시스템 관리
유닛은 아래에 저장됨
- /etc/systemd/system
- 관리자가 수동으로 생성/관리하는 유닛들 저장됨- *.target 으로 된 디렉토리 참고하여 서비스 실행
- /run/systemd/system
- 시스템이 런타임 상태일 때 임시로 유닛 파일 저장하는 곳- 재부팅시 다 날아감 ㅂ2
- /usr/lib/syhstemd/system
- 사용자가 특정 유닛이 포함된 패키지를 설치하면 저장되는 곳
- 유닛 파일의 원본이라 생각해도 됨
-system enable시 여기에 있는 파일이 /etc/systemd/system 에 링크됨
유닛 파일 구성
[Unit]: 유닛의 일반적인 정보 (유닛 설명, 동작, 다른 유닛과의 의존성)
[유닛 유형]: 유닛의 유형 (서비스 유닛 - [Service] , 소켓 유닛 - [Socket])
[Install]: systemctl enable | disable 과 연관된 섹션 ( /etc/systemd/system 에 링크 파일 생성|삭제, 링크 파일 존재 시 시스템 부팅시 해당 유닛 파일 실행)
종류
Service Unit, Target Unit, Automount Unit, Mount Unit, Device Unit, Path Unit, Scope Unit, Slice Unit, Snapshot Unit, Socket Unit, Swap Unit, Timer Unit
명령어
systemctl start | stop | status [서비스명]
부팅 시 유닛 실행 비/활성화
systemctl enable | disable [서비스명]
실행 중인 유닛 확인
systemctl list-units
유닛 개별 상태/활성화 확인
systemctl is-active | is-enabled [서비스명]
*init 에선 service [서비스명] start | stop | status
log
시스템에서 발생한 이벤트를 분류하여 기록한 파일
systemd-journald 를 통해 로그 수집 및 관리
logrotate 유틸리티
로그 파일의 크기가 커지면 로그 파일을 읽어오기 위해 많은 메모리 필요, 로그 확인 및 분석도 어려움 -> 로그 파일 순환 필요
로그 파일의 크기가 너무 크거나 일정 기간이 지나면 현재 로그 파일 이름 뒤에 날짜가 추가되고, 날짜가 추가되기 전 파일이름으로 된 새로운 빈파일 생성 (위 사진 참고)
journal 파일 읽기
journal 은 바이너리 파일이라 cat 으로 읽으려하면 읽을 수 없음
journalctl 사용시 journal이 존재하는 디렉터리에 갈 필요없이 journal 을 읽을 수 있는 형태로 보여줌
journal에 setgid 설정이 되어있는 것을 확인할 수 있었다.
보통 특정 데몬이 관리하는 디렉터리에 설정하는데, systemd-journal 이 관리하고 있기 때문에 설정한 것
journal 말고 log file 로 읽기
tail -f [로그파일 경로]
새로운 로그가 올라오면 실시간으로 볼 수 있음
