/proc 파일시스템은 리눅스의 탁월한 특징 중 하나이다. 이를 통해 머신을 끄고 재부팅 하지 않고 OS의 상세한 부분들을 관리할 수 있다.
상업적으로 매우 중요한 시스템을 관리해 본 사람이라면 업타임(uptime)의 가치를 안다. 역으로 말하면 다운타임(downtime)으로 인해 사용자들로부터 듣게될 원성으로 인한 두통을 알 것이다. 기업이 유닉스 서버를 실행하는 이유 중 하나는 유닉스의 신뢰성과 안정성 때문이다. 주의 깊게 관리된다면 한 동안 재부팅 할 필요 없이 지내게 된다. 게다가 서버를 실행상태로 유지하면서 커널 레벨에서 관리 작업도 수행할 수 있다. 하드웨어를 업그레이드하기 위해 시스템을 재시작 해야 하거나 누군가가 전원 코드를 실수로 뺄 수 있다면 서비스에 피해를 주지 않고 관리작업을 수행하는 것을 알아두는 것이 좋다.
이 글에서는 재부팅 없이 다양한 관리 작업을 수행하고 시스템을 변경할 수 있는 방법이 소개되어 있다. 리눅스는 시스템을 실행 상태로 유지 시킨 채 리눅스 기저의 값과 설정을 변경하는 다양한 방법을 제공한다.
Note: 본 자료는 2.4 레벨 커널 기준이다. 일부 옵션과 기능은 다른 커널 버전과 다를 수 있다.
실행중인 커널 매개변수 변경하기
리눅스는 시스템이 실행중인 동안 커널/시스템을 재부팅 할 필요 없이 관리자들이 커널을 변경할 수 있는 깔끔한 방법을 제공한다. 이는 /proc 이라고 하는 가상 파일시스템으로 수행된다. Linux Gazette는 /proc에 관한한 가장 간단하고 쉬운 레퍼런스를 제공한다. (참고자료) 기본적으로 /proc 파일시스템은 실행 커널을 볼 수 있는 시각을 제공한다. 이는 퍼포먼스를 감시하고 시스템 정보를 발견하며 시스템이 어떻게 설정되었는지를 파악하고 그 설정을 변경할 때 유용하다. 이러한 파일시스템을 가상 파일시스템(virtual filesystem)이라고 한다. 실제 파일시스템이 아니기 때문이다. 이것은 일반적인 파일시스템 구조에 어태치된 커널에 의해 제공되어 이에 액세스 할 수 있게 한다.
시스템이 실행중일 때 실행중인 커널 매개변수를 변경하는 몇 가지 방법이 있다는 사실은 커널 설정 변경에 상당한 힘과 유연성을 시스템 관리자들에게 제공해준다고 볼 수 있다. 이러한 유형의 구현은 일부의 리눅스 커널 개발자들에게 영감을 주는 생각이었다. 하지만 힘도 너무 크면 오히려 나쁠 수도 될 수 있지 않은가? 가끔 그렇다. /proc 파일시스템에 있는 무엇인가를 변경한다면 변경하려는 것이 무엇이고 시스템에 미칠 영향에 대해 반드시 알아야한다. 이들은 실제로 유용한 기술이지만 잘못된 행동은 원치 않는 결과를 가져다 줄 수 있다. 이런 작업이 처음이거나 변경으로 인한 결과를 확신하지 못한다면 중요하지 않는 머신에 연습을 먼저 하기 바란다.
어떻게 변경 할 것인가?
우선 커널에 변경을 가하지 않는 방법을 생각해보자. /proc 파일시스템으로 곧바로 뛰어들어 텍스트 에디터에 있는 파일을 열고 변경을 수행하고 파일을 저장하면 안될 두 가지 중요한 이유가 있다:
- 데이터 무결성: 모든 파일들은 실행 시스템을 나타내고 있고 커널이 언제라도 이들 파일 중 어떤 것이라도 변경할 수 있기 때문에 시스템이 데이터를 실행중일 때 에디터를 열고 데이터를 변경한다면 저장을 한다고 해도 커널이 기대하는 것과 다를 수 있다.
- 가상 파일: 모든 파일들은 실제로 존재하는 것이 아니다. 저장된 데이터가 어떻게 동기화 될 수 있겠는가?
따라서 이러한 파일들을 변경할 때의 답은 에디터를 사용하지 않는 것이다. /proc 파일시스템에 있는 모든 것을 변경할 때 echo 명령어를 사용하고 명령행에서 온 아웃풋을 /proc 밑의 선택된 파일에 리다이렉트 해야한다:
echo "Your-New-Kernel-Value" > /proc/your/file
이와 비슷하게 /proc 에서 정보를 보고싶다면 그 목적에 맞게 설계된 명령어를 사용하거나 cat 명령어를 사용한다.
무엇을 변경 할 것인가?
/proc을 잘 사용하기 위해 커널 해커가 될 필요가 없다. 이 파일시스템의 구조에 대한 기본적인 이해만으로도 충분히 도움이 된다.
/proc에 있는 각각의 파일들은 매우 특별한 파일 권한들을 할당받았고 특별한 사용자 아이디에 의해 소유된다. 이는 매우 신중하게 수행되어 정확한 기능이 관리자와 사용자들에게 보일 수 있도록 한다. 특별한 권한이 개별 파일에 어떤 일을 수행하는지를 다음과 같이 요약했다:
- Read-only: 사용자가 변경할 수 없는 파일: 시스템 정보를 나타내는데 사용됨.
- Root-write: 파일이
/proc에서 쓰기가 가능하다면, 루트(root) 사용자만 쓸 수 있음.
- Root-read: 일반적인 시스템 사용자는 볼 수 없고 루트 사용자만 볼 수 있는 파일.
- Other: 여러가지 이유로 위 세 개의 경우가 섞인 것도 있다.
/proc에 대한 매우 광범위한 일반화는 /proc/sys 디렉토리를 제외하고 대부분 읽기 전용이라는 것을 알게 될 것이다. 이 디렉토리는 대부분의 커널 매개변수를 갖고 있으며 시스템이 실행되는 동안 변경되도록 설계되었다.
Making changes
/proc의 각 파일에 대한 정확한 정보와 사용법을 이 글에서는 다루지 않겠다. 이 글에서 다루어지지 않은 /proc 파일에 대한 자세한 정보의 경우, 최상의 소스는 리눅스 커널 소스 그 자체일 것이다. 매우 훌륭한 문서까지 포함되어 있다. /proc에 있는 다음 파일들은 시스템 관리자들에게 유용하다.
/proc/scsi
시스템 관리자로서 배워두면 가장 유용할 것 중 하나이다. 사용가능한 핫스왑(hot-swap) 드라이브가 있을 때 시스템을 재부팅하지 않고 더 많은 디스크 공간을 추가하는 방법이다. /proc을 사용하지 않고, 드라이브를 삽입할 수 있으나 시스템이 새로운 디스크를 인식하도록 하려면 재부팅해야 한다. 다음과 같은 명령어로 새로운 드라이브를 시스템이 인식하도록 할 수 있다:
echo "scsi add-single-device w x y z" > /proc/scsi/scsi
이 명령어가 올바르게 작동하도록 하려면 매개변수 값인 w, x, y, z를 정확히 해야한다:
- w는 첫 번째 어댑터가 0 인 호스트 어댑터 ID 이다.
- x는 첫 번째 채널이 0 인 호스트 어댑터 상의 SCSI 채널이다.
- y는 디바이스의 SCSI ID 이다.
- z는 첫 번째 LUN이 0 인 LUN 넘버이다.
디스크가 시스템에 추가되면 이전에 포맷된 파일시스템들을 마운트하거나 포맷을 시작할 수 있다. 디스크가 어떤 디바이스가 도리지 불확실하거나 기존에 존재하는 파티션을 점검하고 싶다면 fdisk -l 같은 명령어를 사용하면 된다.
바꿔 말하면 재부팅 필요 없이 시스템에서 디바이스를 제거하는 명령어는 다음과 같다:
echo "scsi remove-single-device w x y z" > /proc/scsi/scsi
이 명령어를 입력하고 시스템에서 핫스왑 SCSI 디스크를 제거하기 전에 디스크에서 파일시스템을 먼저 언마운트한다.
/proc/sys/fs/
/proc/sys/fs/file-max
이것은 할당받을 수 있는 최대 파일 핸들 수를 지정한다. 열린 파일의 최대 수가 다 되었기 때문에 더 이상의 파일을 열 수 없다는 에러 메시지를 사용자가 받는다면 이 값을 늘려야한다. 수는 제한 없이 설정될 수 있고 파일에 새로운 숫자 값을 작성하여 변경할 수 있다.
기본 설정: 4096
/proc/sys/fs/file-nr
이 파일은 file-max와 관련이 있고 세 개의 값을 보유하고 있다:
- 할당받은 파일 핸들의 수
- 사용된 파일 핸들의 수
- 최대 파일 핸들의 수
이 파일은 읽기 전용이며 정보 전달만을 목적으로 한다.
/proc/sys/fs/inode-*
"inode"라는 이름으로 시작하는 모든 파일은 "file"로 시작하는 파일과 같은 작동을 수행하지만, 파일 핸들 대신 inode와 관련된 작동을 수행한다.
/proc/sys/fs/overflowuid & /proc/sys/fs/overflowgid
이것은 16 비트 사용자와 그룹 ID를 지원하는 모든 파일시스템용 User ID (UID)와 Group ID (GID)를 갖고있다. 이 값들은 변경될 수 있지만 원하면 그룹과 패스워드 파일 엔트리를 변경하는 것이 더 쉽다.
기본 설정: 65534
/proc/sys/fs/super-max
이것은 수퍼 블록 핸들러의 최대 수를 지정한다. 마운트 한 모든 파일시스템은 수퍼 블록을 사용하여 많은 파일시스템들을 마운트하더라도 실행 될 수 있도록 할 수 있다.
기본 설정: 256
/proc/sys/fs/super-nr
현재 할당된 수퍼 블록의 수 이다. 이 파일은 읽기 전용이며 정보 전달만을 목적으로 한다.
/proc/sys/kernel
/proc/sys/kernel/acct
프로세스 어카운딩이 로그를 포함하고 있는 파일시스템 상의 빈 공간의 양을 기반을 해서 발생할 경우를 제어하는 세 개의 설정 가능한 값을 갖고있다:
- 빈 공간이 이 비율 이하가 되면 프로세스 어카운팅은 멈춘다.
- 빈 공간이 이 비율 이상이 되면 프로세스 어카운딩이 시작된다.
- 다른 두 개의 값이 검사되는 (초당) 빈도수.
이 파일에서 값을 변경하려면 스페이스로 분리된 숫자 리스트로 echo 해야한다.
기본 설정: 2 4 30
이 값들은 로그를 포함하고 있는 파일시스템의 빈 공간이 2% 미만이라면 어카운팅을 멈춘다. 그리고 빈 공간이 4% 이상 이라면 다시 시작한다. 검사는 30초 마다 이루어진다.
/proc/sys/kernel/ctrl-alt-del
이 파일은 시스템이 ctrl+alt+delete 키 조합을 받을 때 어떻게 반응하는지를 제어하는 바이너리 값을 갖고 있다. 두 개의 값은 다음과 같은 것을 나타낸다:
- 0 값은 ctrl+alt+delete가 트랩(trap)되어 init 프로그램으로 보내지는 것을 의미한다. 셧다운 명령어를 입력한 것 처럼 시스템이 정지하고 재시작하도록 한다.
- 1 값은 ctrl+alt+delete 트랩되지 않고 어떤 깨끗한 셧다운도 수행되지 않을 것을 의미한다. 전원을 끈 것과 같은 이치이다.
기본 설정: 0
/proc/sys/kernel/domainname
이를 사용하여 네트워크 도메인 이름을 설정할 수 있다. 기본 값이 없으며 이미 설정되었을 수도 아닐 수도 있다.
/proc/sys/kernel/hostname
기본 값이 없으며 이미 설정되었을 수도 아닐 수도 있다. 네트워크 호스트 이름을 설정할 수 있다.
/proc/sys/kernel/msgmax
이것은 하나의 프로세스에서 다른 프로세스로 보내질 수 있는 최대 메시지 사이즈를 지정한다.
기본 설정: 8192
/proc/sys/kernel/msgmnb
하나의 메시지 큐에서의 최대 바이트 수를 지정한다.
기본 설정: 16384
/proc/sys/kernel/msgmni
최대 메시지 큐 식별자의 수를 지정한다.
기본 설정: 16
/proc/sys/kernel/panic
"커널 패닉"으로 인해 재부팅 되기 전에 커널이 기다려야 할 시간을 나타낸다. 0초 설정은 커널 패닉 시 재부팅 할 수 없다.
기본 설정: 0
/proc/sys/kernel/printk
중요성을 기준으로 해서 로깅 메시지가 전송될 곳을 지정하는 숫자 값을 갖고 있다:
- Console Log Level: 이 값보다 높은 우선순위를 지닌 메시지들은 콘솔에 프린트된다.
- Default Message Log Level: 우선순위가 없는 메시지들은 이 우선순위로 프린트된다.
- Minimum Console Log Level: Console Log Level이 설정될 수 있는 최소(가장 높은 우선순위) 값.
- Default Console Log Level: Console Log Level 용 기본 값.
기본 설정: 6 4 1 7
/proc/sys/kernel/shmall
주어진 지점의 시스템에서 사용될 수 있는 총 공유 메모리 (바이트) 양.
기본 설정: 2097152
/proc/sys/kernel/shmax
커널에 허용된 최대 공유 메모리 세그먼트 사이즈 (바이트)를 지정한다.
기본 설정: 33554432
/proc/sys/kernel/shmmni
전체 시스템을 위한 최대 공유 메모리 세그먼트의 수.
기본 설정: 4096
/proc/sys/kernel/sysrq
0이 아닐 때 System Request Key를 활성화한다.
기본 설정: 0
/proc/sys/kernel/threads-max
커널에서 사용할 수 있는 최대 쓰레드의 수.
기본 설정: 2048
/proc/sys/net
/proc/sys/net/core/message_burst
새로운 경고 메시지를 작성하는데 필요한 시간 (1/10 초); 이 시간동안 받은 다른 경고 메시지들은 누락된다. 시스템을 메시지로 넘쳐나게 하려는 사람들의 "Denial of Service" 공격을 방지하는데 사용된다.
기본 설정: 50 (5초)
/proc/sys/net/core/message_cost
모든 경고 메시지와 관련된 비용의 값을 보유하고 있다. 값이 높을 수록 경고 메시지가 더욱 무시된다.
기본 설정: 5
/proc/sys/net/core/netdev_max_backlog
인터페이스가 커널이 처리할 수 있는 것보다 빠른 패킷을 받았을 때 큐에 허용된 최대 패킷 수를 제공한다.
기본 설정: 300
/proc/sys/net/core/optmem_max
소켓 당 할당된 최대 버퍼 사이즈를 지정한다.
/proc/sys/net/core/rmem_default
수신 소켓 버퍼의 기본 사이즈(바이트) 이다.
/proc/sys/net/core/rmem_max
수신 소켓 버퍼의 최대 사이즈(바이트) 이다.
/proc/sys/net/core/wmem_default
송신 소켓 버퍼의 기본 사이즈(바이트) 이다.
/proc/sys/net/core/wmem_max
송신 소켓 버퍼의 최대 사이즈(바이트) 이다.
/proc/sys/net/ipv4
모든 IPv4와 IPv6 매개변수는 커널 소스 문서에 모두 문서화되었다. /usr/src/linux/Documentation/networking/ip-sysctl.txt 파일을 참조하기 바란다.
/proc/sys/net/ipv6
IPv4와 같다.
/proc/sys/vm
/proc/sys/vm/buffermem
버퍼 메모리에 사용될 총 시스템 메모리(퍼센트) 양을 제어한다. 파일에 공간 분리 리스트를 작성하여 설정될 수 있는 세 개의 값을 갖고 있다:
- 버퍼에 사용될 최소 메모리 비율.
- 남아있는 시스템 메모리가 적을 경우 시스템 메모리가 없어질 때 시스템은 이 정도의 버퍼 메모리를 유지하려고 한다.
- 버퍼에 사용될 최대 메모리 비율.
기본 설정: 2 10 60
/proc/sys/vm/freepages
시스템이 다른 레벨의 빈 메모리에 어떻게 반응할 것인지를 제어한다. 공간 분리 리스트를 파일에 작성하여 설정할 수 있는 세 개의 값이 있다:
- 시스템에서 비어있는 페이지의 수가 최소 한계에 다다랐다면 커널에만 더 많은 메모리를 할당하도록 허용된다.
- 시스템에서 비어있는 페이지의 수가 이 한계 밑으로 떨어지면 커널은 공격적으로 빈 메모리로 스와핑을 시작하며 시스템 퍼포먼스를 유지한다.
- 커널은 이 정도의 시스템 메모리를 빈 상태로 유지할 것이다. 이 밑으로 떨어지면 커널 스와핑이 시작된다.
기본 설정: 512 768 1024
/proc/sys/vm/kswapd
커널이 메모리를 스와핑하도록 어떻게 허용할 지를 제어한다. 공간 분리 리스트를 파일에 작성하여 설정할 수 있는 세 개의 값이 있다:
- 커널이 한번에 빈 공간으로 둘 최대 페이지의 수. 스왑으로 대역폭을 늘리려면 이 숫자를 늘린다.
- 각 스왑에 대해 커널이 페이지를 빈 곳으로 유지하는 최대 시간.
- 한 스왑에서 커널이 작성할 수 있는 페이지의 수. 이것은 시스템 퍼포먼스에 가장 큰 영향을 미친다. 값이 클수록 스와핑 될 데이터는 많아지고 디스크 검색에 사용되는 시간은 줄어든다. 하지만 값이 너무 크면 시스템 퍼포먼스에 역효과를 가져온다.
기본 설정: 512 32 8
/proc/sys/vm/pagecache
/proc/sys/vm/buffermem과 같은 작업을 수행하지만 메모리 매핑과 일반적인 파일 캐싱을 위해 작동한다.
영속적인 커널 설정
/proc/sys 디렉토리에는 어떤 커널 매개변수라도 변경할 수 있도록 편리한 유틸리티가 있다. 이를 사용하여 실행 커널을 변경할 수 있지만 시스템 부트에서 실행되는 설정 파일 또한 있다. 이것은 실행 커널을 변경하고 그들을 설정 파일에 추가시켜 시스템 재부팅 후에도 어떤 변경이라도 남아있게 된다.
이 유틸리티는 sysctl 이라고 하며 sysctl(8)의 맨페이지에 모두 문서화 되어 있다. sysctl용 설정 파일은 /etc/sysctl.conf이며 편집 될 수 있다. sysctl.conf(8)에 문서화되어 있다. Sysctl은 /proc/sys 밑에 있는 파일들을 변경될 수 있는 개별 변수들로 취급한다. 따라서, 예를 들어, 시스템에 허용된 최대 파일 핸들의 수를 나타내는 /proc/sys 밑의 파일인 /proc/sys/fs/file-max는 fs.file-max로 나타난다.
이 예제는 sysctl 표기에서 몇 가지 이상한 점을 드러낸다. sysctl은 can only change variables under the /proc/sys 디렉토리 밑에 있는 변수들을 변경할 수 있기 때문에 변수 이름의 일부는 이 디렉토리 밑에 있는 것으로 가정되는 변수로서 무시된다. 디렉토리 분리자(슬래시, /)는 마침표(.)로 변경되었다.
/proc/sys 에 있는 파일들과 sysctl의 변수들 간 변환에 적용되는 두 개의 간단한 규칙이 있다:
- 시작부터
/proc/sys를 누락한다.
- 파일이름에서 슬래시를 마침표로 바꾼다.
이 두 개의 규칙으로 /proc/sys에 있는 모든 파일 이름을 sysctl의 모든 변수 이름으로 바꿀 수 있다. 변수 변환에 대한 일반적인 파일은 다음과 같다:
/proc/sys/dir/file --> dir.file
dir1.dir2.file --> /proc/sys/dir1/dir2/file
변경될 수 있는 모든 변수들을 볼수 있고 이에 더하여 sysctl -a 명령어를 사용하여 그들의 현재 설정을 볼 수 있다.
sysctl를 사용하여 변수들이 변경될 수 있는데 이는 위에 사용된 echo 메소드와 같은 작업을 수행한다:
sysctl -w dir.file="value"
file-max 예제를 다시 사용하여, 다음과 같이 두 개의 메소드 중 하나를 사용하여 이 값을 16384로 변경할 수 있다:
sysctl -w fs.file-max="16384"
또는:
echo "16384" > /proc/sys/fs/file-max
sysctl은 설정 파일을 변경하지 않음을 기억하라. 수동으로 하도록 남겨두었다. 재부팅 후에도 변경을 영속성있게 유지하려면 이 파일을 유지하라.
Note: 모든 배포판이 sysctl을 지원하는 것은 아니다. 이는 특정 시스템의 경우이며, 시스템 부팅 시 실행되도록 하려면 위에 설명된 에코와 리다이렉트 메소드를 사용하여 시작 스크립트에 이 명령어를 추가한다.
시스템 설정을 위한 명령어
시스템이 실행되는 동안 다른 비커널 시스템 매개변수를 변경하고 또한 재부팅 필요 없이 설정을 발효시킬 수 있다. 이들은 주로 서비스, 데몬, 서버로 분류되며 /etc/init.d 디렉토리에 있다. 이 디렉토리에 리스팅될 수 있는 스크립트가 점점 광범위해지기 때문에 여기에서 모든 다양한 설정을 다루기엔 불가능하다. 아래 몇 가지의 예제는 /etc/init.d 스크립트가 다양한 리눅스 배포판에서 어떻게 조작될 수 있는지를 설명하고 있다. 재부팅 필요 없이 설정 데몬과 리로드를 변경하는 것은 유용한 예제이다:
- 웹 서버 설정 변경과 Apache 리로딩
- 원하지 않는 inetd 로그인 서비스 제거
- 네트워크 설정 조작
- NFS를 통한 새로운 파일시스템 반출
- 방화벽 시작/중지
우선, 시스템 서비스를 조직하는 일반적인 방법은 직접 /etc/init.d에 있는 스크립트를 통해서이다. 이 스크립트들은 매개변수를 취하여 그들이 제어할 서비스를 조작한다. 유효한 작동이 무엇인지 보기위해 매개변수 없이 스크립트 이름을 입력할 수 있다. 일반적인 매개변수들은 다음과 같다:
- start: 중지된 서비스 시작
- stop: 실행되는 서비스 중지
- restart: 멈춘 후 실행 서비스 시작. 또는 중지된 서비스 시작
- reload: 연결을 끊지 않은 채 서비스 설정 리로드
- status: 서비스의 실행 여부를 나타내는 아웃풋
예를 들어 다음의 명령어는 연결된 사용자 세션을 종료하지 않고 xinetd 설정을 리로드 한다:
/etc/init.d/xinetd reload
Red Hat은 service 명령어를 제공하는데 이는 서비스를 조작한다. service 명령어는 스크립트 이름을 타이핑할 때와 같은 기능을 제공한다. 신택스는 다음과 같다:
service script-name [parameter]
예를 들어:
service xinetd reload
SuSE 역시 rc 라는 명령어를 제공한다. 이는 서비스 명령어와 비슷하다. 하지만 명령어와 스크립트 이름 사이에 공간이 없다:
rc{script-name} parameter
예:
rcapache start
참고자료
필자소개
 |
|
|
Graham은 IBM의 IT 전문가로 활동하고 있다.
|
