시스템 관리자의 가장 중요한 책임 중 하나는 파일 서버 시스템의 프로세스가 제대로 실행되고 있는지 확인하는 것입니다. 모든 파일 서버 시스템에서 실행되는 BOS 서버는 시스템 상의 다른 AFS 서버 프로세스를 계속 모니터하여 여러분의 책임을 많이 덜어 줍니다. 또한 실패한 프로세스를 자동으로 재시작하고 상호 의존성을 고려하여 재시작 순서를 지정할 수 있습니다.
여러 다른 파일 서버 시스템에서 다른 프로세스들이 함께 실행되므로 각 파일 서버 시스템의 BOS 서버가 모니터해야 할 프로세스를 정의해야 합니다 (프로세스 상태 제어 및 확인 참고).
BOS 서버가 수정할 수 있는 루틴 유지관리를 수행하거나 문제점(예: 데이터베이스 복제 또는 상호 인증과 관련된 문제)을 수정하기 전에 서버 프로세스 상태를 직접 제어하는 것이 필요할 수 있습니다. 이러한 경우에 bos 명령을 실행하여 BOS 서버를 통해 프로세스 상태를 제어해야 합니다.
이 장에서는 지정된 명령을 사용하여 다음 타스크를 수행하는 방법을 설명합니다.
| 프로세스 상태 검토 | bos status |
| BosConfig file 파일의 정보 검토 | bos status 명령과 -long 플래그 |
| 프로세스 인스턴스 작성 | bos create |
| 프로세스 정지 | bos stop |
| 정지된 프로세스 시작 | bos start |
| 프로세스 일시 정지 | bos shutdown |
| 일시 정지된 프로세스 시작 | bos startup |
| 프로세스 정지 후 즉시 재시작 | bos restart |
| 모든 프로세스 정지 후 즉시 재시작 | bos restart 명령과 함께 -bosserver 플래그 |
| BOS 서버의 재시작 시간 검토 | bos getrestart |
| BOS 서버의 재시작 시간 설정 | bos setrestart |
| 로그 파일 검토 | bos getlog |
| 원격으로 명령 실행 | bos exec |
이 절에서는 AFS 서버 시스템에서 실행될 수 있는 여러 다른 서버 프로세스를 설명합니다. 다중 서버 시스템이 있는 셀의 모든 시스템에서 모든 프로세스가 반드시 실행되는 것은 아닙니다.
AFS 서버 프로세스는 그 컨텍스트에 따라 다음의 세 가지 방식으로 언급됩니다.
다음 절에서는 이러한 프로세스를 사용하게 되는 일부 관리 타스크와 프로세스의 각 이름을 지정합니다. 서버에 대한 좀더 일반적인 설명을 보려면 AFS 서버 프로세스 및 캐쉬 관리 프로그램을 참조하십시오.
모든 AFS 서버 시스템에서 실행되는 bosserver 프로세스는 시스템에서 실행되는 다른 AFS 서버 프로세스를 모니터하는 책임을 맡은 BOS(Basic OverSeer) 서버입니다. 프로세스가 실패하면 BOS 서버는 사용자가 개입하지 않아도 프로세스를 자동으로 재시작할 수 있습니다. 또한 다중 구성요소 프로세스(예: fs 프로세스 모음: 파일 서버, 볼륨 서버 및 구조 프로그램에서 설명하는 fs 프로세스)를 가진 프로세스를 재시작할 때 상호 의존성을 고려합니다.
BOS 서버는 자신을 모니터하거나 재시작하지 않으므로 bos status 명령의 출력에 나타나지 않습니다. 이 서버는 ps 명령의 출력에 /usr/afs/bin/bosserver로서 나타납니다.
시스템 관리자라면 bos 명령을 실행하여 다음 유형의 타스크를 수행할 때 BOS 서버에 접속해야 합니다.
데이터베이스 서버 시스템에서 실행되는 buserver는 백업 서버입니다. 이 서버는 백업 시스템 구성 및 백업 데이터베이스의 조작에 대한 정보를 유지 관리합니다.
일반적인 이름이 지정되는 경우 프로세스는 bos status 명령 출력에서 buserver로 나타납니다. 이 서버는 ps 명령의 출력에 /usr/afs/bin/buserver로서 나타납니다.
시스템 관리자라면 볼륨에서 영구 기억영역으로 데이터를 덤프하거나 데이터를 AFS로 복원하는 백업 데이터베이스에 백업 시스템 구성 정보를 변경하는 것과 같은 정보를 처리하는 backup 명령을 실행할 때 백업 서버에 접속해야 합니다. AFS 백업 시스템 구성 및 AFS 데이터 백업 및 복원을 참조하십시오.
모든 파일 서버 시스템에서 실행되는 fs 프로세스는 파일 서버, 볼륨 서버 및 구조 프로그램의 세 가지 구성요소 프로세스를 조합합니다. 세 가지 구성요소는 독립적인 기능을 수행하지만 다음 이유로 인해 단일 프로세스로 제어됩니다.
파일 서버 구성요소는 파일 및 디렉토리 레벨에서 AFS 데이터를 처리하고 응용 프로그램과 표준 운영 체제 명령에서 요구하는 대로 파일 시스템 요소를 처리합니다. 그 기본 임무는 요청된 파일을 클라이언트 시스템을 전달하고 클라이언트가 종료될 때 이들 파일을 다시 서버 시스템에 저장하는 것입니다. 또한 각 파일 및 디렉토리에 대한 상태 및 보호 정보를 유지 관리하기도 합니다. 이 구성요소는 정상 작동 중에 계속 실행됩니다.
볼륨 서버 구성요소는 파일 및 디렉토리 레벨이 아닌 완전한 볼륨 레벨에서 AFS 데이터를 처리합니다. vos 명령이 실행될 경우 이 구성요소는 다른 작업 도중에 전체 볼륨을 작성, 제거, 이동, 덤프 및 복원합니다. 이 구성요소는 정상 작동 중에 계속 실행됩니다.
구조 프로그램 구성요소는 다른 두 프로세스 중 하나에 장애가 발생한 후에만 실행됩니다. 이 구성요소는 파일 시스템의 내부 일관성을 확인하고 발견한 오류를 수정합니다.
일반적인 이름이 지정되는 경우 프로세스는 bos status 명령 출력에서 fs로 나타납니다. 보조 메시지가 나타나서 파일 서버 또는 구조 프로그램 구성요소의 상태를 보고합니다.프로세스 상태와 BosConfig 파일의 정보 표시하기를 참조하십시오.
fs 프로세스의 구성요소 프로세스는 다음과 같이 ps 명령 출력에서 개별적으로 나타납니다. fs 프로세스 자체에 대한 항목은 없습니다.
캐쉬 관리 프로그램은 AFS 파일 또는 디렉토리의 데이터나 상태 정보를 액세스할 때마다 또는 UNIX cp 및 ls 명령과 같은 파일 처리 명령을 실행할 때 사용자 대신 파일 서버 구성요소에 접속합니다. 사용자는 다음 기능을 수행하는 fs 명령을 실행하여 파일 서버에 직접 접속할 수 있습니다.
볼륨을 작성, 제거, 복제, 이동, 이름 변경, 다른 형식으로 변경 또는 구조하는 등의 방법으로 볼륨을 처리하는 vos 명령을 실행할 때 볼륨 서버 구성요소를 접속해야 합니다. 지침을 보려면 볼륨 관리를 참조하십시오.
구조 프로그램은 보통 장애가 발생하는 경우에 자동으로 실행됩니다. 볼륨 구조에서 설명하는 것처럼 bos salvage 명령을 사용하여 구조 프로그램을 시작할 수도 있습니다.
데이터베이스 서버 시스템에서 실행되는 kaserver 프로세스는 AFS 보안의 여러 측면을 담당하는 인증 서버입니다. 이 서버는 암호를 요구하여 AFS 사용자의 신원을 확인합니다. 또한 인증 데이터베이스에 모든 AFS 서버 암호화 키와 사용자 암호를 유지 관리합니다. 인증 서버의 티켓 부여 서비스(TGS) 모듈은 AFS 클라이언트 및 서버 프로세스가 보안 연결을 형성할 때 사용하는 공유 비밀을 작성합니다.
일반적인 이름이 지정되는 경우 프로세스는 bos status 명령 출력에서 kaserver로 나타납니다. ka 문자열은 Kerberos 인증을 상징하는 것으로 AFS의 인증 프로토콜이 원래 Massachusetts Institute of Technology's Project Athena에서 개발된 Kerberos에 기반을 두고 있음을 반영합니다.
이 서버는 ps 명령의 출력에 /usr/afs/bin/kaserver로서 나타납니다.
시스템 관리자라면 kas 명령을 실행하여 다음 유형의 타스크를 수행할 때 인증 서버에 접속해야 합니다.
데이터베이스 서버 시스템에서 실행되는 ptserver 프로세스는 보호 서버입니다. 그 기본 임무는 사용자, 시스템 및 그룹 항목을 포함하는 보호 데이터베이스를 유지 관리하는 것입니다. 보호 서버는 AFS ID를 할당하고 이들과 이름 간의 맵핑을 유지 관리합니다. 파일 서버는 사용자가 요청된 작업을 수행할 권한이 있는지 확인할 때 보호 서버에 문의합니다.
일반적인 이름이 지정되는 경우 프로세스는 bos status 명령 출력에서 ptserver로 나타납니다. 이 서버는 ps 명령의 출력에 /usr/afs/bin/ptserver로서 나타납니다.
시스템 관리자라면 pts 명령을 실행하여 다음 유형의 타스크를 수행할 때 보호 서버에 접속해야 합니다.
모든 서버 시스템에서 실행되는 runntp 프로세스는 서버 시스템의 하드웨어 시계를 동기화하는 NTPD(Network Time Protocol Daemon)에 대한 제어기 프로그램입니다. 아직 서버 시스템에서 NTP나 다른 시간 동기화 프로토콜을 실행하고 있지 않으면 runntp 프로세스를 실행할 수 있습니다.
데이터베이스 서버 시스템의 시계는 AFS의 분산 데이터베이스 기술(Ubik)이 시계의 시간이 큰 차이가 없을 때만 제대로 기능하기 때문에 동기화를 이루어야 합니다(적절한 Ubik 작업을 위한 셀 구성 참고). 파일 서버 시스템의 시계는 파일 서버가 파일에 수정 시간 소인을 설정할 뿐 아니라 일반적인 구성에서 AFS 클라이언트 시스템에 대한 시간 소스로 작동하기 때문에 잘못되면 안됩니다.
일반적인 이름이 지정되는 경우 프로세스는 bos status 명령 출력에서 runntp로 나타납니다. 이 프로세스는 ps 명령의 출력에서 /usr/afs/bin/runntp로서 나타납니다. ps 명령의 출력에는 ntpd라는 항목도 들어 있습니다. 그 정확한 양식은 사용자가 runntp 명령에 제공한 인수에 따라 달라집니다.
시스템 관리자라면 AFS 빠른 시작의 지침에 따라 NTPD를 설치할 때 직접 NTPD에 접속할 필요가 없습니다.
갱신 서버는 두 가지 별도의 부분으로 구성됩니다. 각각은 다른 유형의 서버 시스템에서 실행됩니다. upserver 프로세스는 갱신 서버의 서버 부분입니다. 그 기능은 다음과 같이 사용하는 AFS 버전에 따라 달라집니다.
upclient 프로세스는 갱신 서버의 클라이언트 부분으로 서버 부분과 마찬가지로 그 기능은 사용되는 AFS 버전에 따라 달라집니다.
일반적인 이름이 지정된 경우 bos status 명령의 출력에서 서버 부분은 upserver로 나타나고 클라이언트 부분은 upclientbin 및 upclientetc로 나타납니다. ps 명령의 출력에서 서버 부분은 /usr/afs/bin/upserver로 나타나고 클라이언트 부분은 /usr/afs/bin/upclient로 나타납니다.
일단 갱신 서버를 설치했으면 갱신 서버에 직접 접속할 필요가 없습니다. 이 서버는 사용자가 bos 명령을 사용하여 분배하는 파일을 변경할 때마다 자동으로 작동됩니다.
데이터베이스 서버 시스템에서 실행되는 vlserver 프로세스는 각 볼륨을 저장하는 파일 서버 시스템을 자동으로 추적하여 그 위치를 클라이언트 응용 프로그램에 가시적으로 알려 주는 볼륨 위치(VL) 서버입니다.
일반적인 이름이 지정되는 경우 프로세스는 bos status 명령 출력에서 vlserver로 나타납니다. 이 서버는 ps 명령의 출력에서 /usr/afs/bin/vlserver로 나타납니다.
시스템 관리자라면 볼륨의 상태를 변경하는 vos 명령을 실행할 때 VL 서버에 접속해야 합니다(VLDB에 상태 변경 내용을 저장합니다).
서버 시스템에서 실행되는 AFS 서버 프로세스를 정의하려면 bos create 명령을 사용하여 로컬 /usr/afs/local/BosConfig 파일에 이들 프로세스에 대한 항목을 작성하십시오. BOS 서버는 BosConfig 파일에서 Run 상태 플래그가 붙은 프로세스를 모니터하고 이들 프로세스에 장애가 발생한 경우 자동으로 재시작을 시도합니다. 프로세스 항목을 작성한 후에 bos 집합으로부터 다른 명령을 사용하여 원하는 대로 프로세스를 정지 및 시작하거나 상태 플래그를 변경할 수 있습니다.
bos 명령을 사용하지 않고 직접 BosConfig 파일을 편집하지 않도록 하십시오. 이와 마찬가지로 서버 프로세스를 BosConfig 파일에 나열하지 않고 서버 프로세스를 실행하거나 UNIX kill 명령과 같은 프로세스 종료 명령을 사용하여 프로세스를 정지하는 것은 바람직하지 못합니다.
BosConfig 파일의 프로세스 항목에는 다음 정보가 들어 있습니다.
BosConfig 파일은 프로세스 정의와 함께 새 2진 파일을 포함하는 프로세스 및 BOS 서버를 포함하는 모든 서버 프로세스에 대한 자동 재시작 시간을 기록합니다. BOS 서버의 재시작 시간 설정을 참조하십시오.
BOS 서버는 시작되거나 재시작될 때마다 BosConfig 파일을 읽어 어떤 프로세스를 시작하여 모니터할지 확인합니다. 또한 그 정보를 커널 메모리에 전송하고 다음 재시작 때까지 BosConfig 파일을 다시 읽지 않습니다. 이것은 BOS 서버의 메모리 상태가 BosConfig 파일과는 독립적으로 변경될 수 있음을 의미합니다. 예를 들어 프로세스를 정지하고 BosConfig 파일에서 그 상태 플래그를 Run으로 남겨 두거나 BosConfig 파일에서 그 상태 플래그가 NotRun인 경우에도 프로세스를 시작할 수 있습니다.
잠깐 동안 데이터베이스 서버 프로세스(인증 서버, 백업 서버, 보호 서버 또는 볼륨 위치 서버)를 시작하거나 정지할 때 AFS 빠른 시작에서 데이터베이스 서버 시스템의 설치 또는 제거에 대한 지침을 따라야 합니다. 다음은 올바른 AFS 기능을 유지하기 위해 수행해야 하는 타스크에 대한 요약입니다.
일반적인 셀 구성에서 각 시스템 유형을 가진 하나의 서버 시스템은 2진 분산 시스템으로 작동되고 갱신 서버의 서버 부분(upserver 프로세스)를 실행하여 그 /usr/afs/bin 디렉토리의 내용을 분배합니다. 해당 시스템 유형을 가진 다른 서버 시스템은 2진 분산 시스템을 참조하는 갱신 서버 클라이언트 부분(일반적으로 upclientbin라고 함)의 인스턴스를 실행합니다.
미국판 AFS를 실행하는 경우 설치하는 첫번째 서버 시스템이 시스템 제어 시스템으로 작동하는 것이 일반적이며 이 시스템은 갱신 서버의 서버 부분(upserver 프로세스)를 실행하여 그 /usr/afs/etc 디렉토리의 내용을 분배합니다. 다른 모든 서버 시스템은 시스템 제어 시스템을 참조하는 갱신 서버 클라이언트 부분(일반적으로 upclientetc라고 함)의 인스턴스를 실행합니다.
| 주: | 각국 언어판 AFS를 사용하는 경우 /usr/afs/etc 디렉토리의 내용을 분배하기 위해 갱신 서버를 사용하지 않도록 하십시오 (시스템 제어 시스템을 실행하지 않게 됨). 이 장에 나오는 프로세스에 대한 모든 참조를 무시하십시오. |
현재 2진 분산 또는 시스템 제어 시스템의 역할 중 하나를 수행하고 있는 시스템을 완전히 중단하지 않는 한 이들 시스템의 책임을 다른 시스템으로 옮기지 않는 것이 간단합니다. 갱신 서버를 실행하면 보통 거의 처리 로드가 부과되지 않습니다. 기능을 이동해야만 하는 경우 다음의 관련 타스크를 수행하십시오.
서버 시스템의 AFS 서버 프로세스의 상태를 표시하려면 bos status 명령을 실행하십시오. -long 플래그를 추가하면 그 유형 및 명령 매개변수를 포함하여 BosConfig 파일에 있는 각 프로세스 항목의 대부분의 정보가 표시됩니다. 또한 /usr/afs 디렉토리에 있는 파일 및 하위 디렉토리에 대한 모드 비트가 기대값과 일치하지 않을 경우 경고 메시지를 표시합니다.
% bos status <machine name> [<server process name>+] [-long]
여기서
출력에는 각 프로세스에 대한 항목이 들어 있으며 다음 문자열 중 하나를 사용하여 프로세스의 상태를 나타냅니다.
fs 프로세스의 출력에는 항상 Auxiliary status라고 표시된 메시지가 포함되며 이 메시지는 다음 중 하나가 될 수 있습니다.
cron 프로세스의 출력에는 명령이 다음에 실행되도록 예정되어 있을 때 보고할 Auxiliary status 메시지가 포함되어 있습니다. 다음 예제를 참조하십시오.
프로세스의 출력에는 보충 메시지 has core file이 포함되어 있어 특정 시점에 프로세스가 실패했으며 /usr/afs/logs 디렉토리에 코어 파일이 생성되었음을 나타냅니다. 대부분의 경우에 BOS 서버는 프로세스를 재시작할 수 있으며 프로세스는 실행되고 있습니다.
다음 예에는 backupusers라고 하는 사용자 정의 cron 항목이 들어 있습니다.
% bos status fs3.abc.com
Instance kaserver, currently running normally.
Instance ptserver, currently running normally.
Instance vlserver, has core file, currently running normally.
Instance buserver, currently running normally.
Instance fs, currently running normally.
Auxiliary status is: file server running.
Instance upserver, currently running normally.
Instance runntp, currently running normally.
Instance backupusers, currently running normally.
Auxiliary status is: run next at Mon Jun 7 02:00:00 1999.
bos status 명령에 -long 플래그를 포함시키면 출력의 프로세스 항목에는 BosConfig 파일에서 가져온 다음의 추가 정보가 포함됩니다.
또한 BOS 서버가 /usr/afs에 있는 특정 파일 및 디렉토리에 대한 모드 비트가 예상한 값을 벗어나는 것을 발견하면 다음의 경고 메시지를 인쇄합니다.
Bosserver process reports inappropriate access on server directories
/usr/afs 디렉토리의 디렉토리와 파일에 대해 예상되는
보호 조치는 다음과 같습니다. 물음표는 BOS 서버가 모드 비트를 확인하지
않음을 나타냅니다. 이들 파일 및 디렉토리에 대한 보호 설정에 대한 자세한
정보를 보려면 AFS 빠른 시작을 참조하십시오.
| /usr/afs | drwxr?xr-x |
| /usr/afs/backup | drwx???--- |
| /usr/afs/bin | drwxr?xr-x |
| /usr/afs/db | drwx???--- |
| /usr/afs/etc | drwxr?xr-x |
| /usr/afs/etc/KeyFile | -rw????--- |
| /usr/afs/etc/UserList | -rw?????-- |
| /usr/afs/local | drwx???--- |
| /usr/afs/logs | drwxr?xr-x |
다음은 시스템 fs3.abc.com에서 실행되는 fs 프로세스에 대한 확장된 출력 결과를 보여 줍니다.
% bos status fs3.abc.com fs -long
Instance fs, (type is fs), currently running normally.
Auxiliary status is file server running
Process last started at Mon May 3 8:29:19 1999 (3 proc starts)
Last exit at Mon May 3 8:29:19 1999
Last error exit at Mon May 3 8:29:19 1999, due to shutdown request
Command 1 is '/usr/afs/bin/fileserver'
Command 2 is '/usr/afs/bin/volserver'
Command 3 is '/usr/afs/bin/salvager'
서버 시스템에서 새 AFS 서버 프로세스를 시작하려면 bos create 명령을 실행하십시오. 이 명령은 /usr/afs/local/BosConfig 파일에 항목을 작성하고, 이 파일과 BOS 서버의 메모리에서 프로세스의 상태 플래그를 모두 Run으로 설정하고, 즉시 프로세스를 실행합니다. 새 프로세스에 대한 2진 파일은 보통 /usr/afs/bin 디렉토리에 미리 설치되어 있어야 합니다(새 2진 파일 설치 참고).
프로세스를 영구히 정지하려면 먼저 bos stop 명령을 실행하십시오. 이 명령은 BosConfig 파일과 BOS 서버의 메모리에서 프로세스의 상태 플래그를 NotRun으로 설정합니다. 이 상태 플래그는 bos status 명령의 출력에는 disabled로 표시되어 있습니다. 원하는 경우 bos delete 명령을 실행하여 BosConfig 파일에서 프로세스의 항목을 제거하십시오. 그러면 이 프로세스는 더 이상 bos status 명령의 출력에 나타나지 않습니다.
| 주: | 이 절에서 설명하는 방식대로 데이터베이스 서버 프로세스를 시작하거나 정지하는 경우 AFS 빠른 시작에서 데이터베이스 서버 시스템 작성 또는 제거에 대한 자세한 지침을 참조하십시오. 주어진 시스템에서 하나의 데이터베이스 서버 프로세스를 실행하는 경우 이들을 모두 실행해야 합니다. 자세한 정보를 보려면 데이터베이스 서버 프로세스 시작 및 정지에 대하여를 참조하십시오. 이와 마찬가지로 시스템 제어 시스템이나 분산 2진 시스템에서 upserver 프로세스를 정지하는 경우 갱신 서버 시작 및 정지에 대하여에서 설명하는 추가 타스크를 완료해야 합니다. |
% bos listusers <machine name>
2진 파일이 없으면 적절한 시스템 유형의 분산 2진 시스템에 이들 2진 파일을 설치하고 갱신 서버가 이들 파일을 이 시스템에 복사할 때까지 기다리십시오. 지침을 보려면 새 2진 파일 설치를 참조하십시오.
% ls /usr/afs/bin
% bos create <machine name> <server process name> \
<server type>
<command lines>+ [ -notifier <Notifier program>]
여기서
Simple 프로세스의 경우 로컬 디스크에 잇는 프로세스 2진 파일의 전체 경로 이름을 제공하십시오(예: 보호 서버의 경우 /usr/afs/bin/ptserver). 초기화 명령 옵션을 포함시키는 경우에는 전체 명령을 큰 따옴표(" ")로 묶으십시오. upclient 프로세스는 필수 인수를 가지며 다른 모든 프로세스에 대한 명령은 선택적 인수를 취합니다.
fs 프로세스의 경우 fileserver, volserver 및 salvager의 순서대로 각 구성요소 프로세스에 대해 로컬 디스크 2진 파일의 완전한 경로 이름을 제공하십시오. 표준 2진 디렉토리는 /usr/afs/bin입니다. 초기설정 명령의 옵션을 포함시키는 경우 전체 명령을 큰 따옴표(" ")로 묶으십시오.
cron 프로세스의 경우 다음의 두 매개변수를 제공하십시오.
다음 예제는 시스템 db2.abc.com의 보호 서버를 정의하고 시작합니다.
% bos create db2.abc.com ptserver simple /usr/afs/bin/ptserver
다음 예제는 시스템 fs6.abc.com의 fs 프로세스를 정의하고 시작합니다.
% bos create fs6.abc.com fs fs /usr/afs/bin/fileserver \
/usr/afs/bin/volserver /usr/afs/bin/salvager
다음 예제는 시스템 fs3.abc.com에서 backupuser 프로세스라고 하는 cron 프로세스를 정의하고 시작합니다. 이 프로세스는 매일 새벽 3시에 실행되도록 예정되어 있습니다.
% bos create fs3.abc.com backupuser cron "/usr/afs/bin/vos backupsys -prefix user -local" 3:00
% bos listusers <machine name>
% bos stop <machine name> <server process name>+ [-wait]
% bos delete <machine name> <server process name>+
여기서
BOS 서버가 더 이상 모니터하려고 시도하지 않도록 프로세스를 정지하려면 bos stop 명령을 실행하십시오. 프로세스의 상태 플래그는 BOS 서버의 메모리와 BosConfig 파일 모두에서 NotRun으로 설정됩니다. 프로세스는 사용자가 그 상태 플래그를 BOS 서버의 메모리와 BosConfig 파일 모두에서 Run으로 설정하는 bos start 명령을 실행할 때까지 다시 실행되지 않습니다(또한 BosConfig 파일에서 상태 플래그를 변경하지 않고도 bos startup 명령을 사용하여 프로세스를 다시 시작할 수 있습니다. 프로세스 일시 정지 및 시작을 참조하십시오).
BosConfig 파일에 BOS 서버에 대한 항목이 없으면 bos stop 및 bos start 명령이 BOS 서버를 제어하지 않습니다. 다른 모든 프로세스와 함께 BOS 서버를 정지한 후 즉시 재시작하려면 프로세스를 정지한 후 즉시 재시작하기에서 설명하는 것처럼 bos restart 명령에 대해 -bosserver 플래그를 사용하십시오.
| 주: | 이 절에서 설명하는 방식대로 데이터베이스 서버 프로세스를 시작하거나 정지하는 경우 AFS 빠른 시작에서 데이터베이스 서버 시스템 작성 또는 제거에 대한 자세한 지침을 참조하십시오. 주어진 시스템에서 하나의 데이터베이스 서버 프로세스를 실행하는 경우 이들을 모두 실행해야 합니다. 자세한 정보를 보려면 데이터베이스 서버 프로세스 시작 및 정지에 대하여를 참조하십시오. 이와 마찬가지로 시스템 제어 시스템이나 분산 2진 시스템에서 upserver 프로세스를 정지하는 경우 갱신 서버 시작 및 정지에 대하여에서 설명하는 추가 타스크를 완료해야 합니다. |
% bos listusers <machine name>
% bos stop <machine name> <server process name>+ [-wait]
여기서
% bos listusers <machine name>
% bos start <machine name> <server process name>+
여기서
때때로 프로세스를 일시적으로 중단해야 하는 경우가 있습니다(예를 들어 구성을 약간 변경하거나 유지 관리를 수행할 때). 이 절에서 설명하는 명령은 BOS 서버의 메모리에서만 프로세스의 상태를 변경합니다. 그 효과는 즉각적이며 사용자가 메모리 상태를 다시 변경할 때까지 지속됩니다(또는 BOS 서버가 BosConfig 파일의 항목에 따라 프로세스를 시작하는 BOS 서버 재시작 시간까지).
BOS 서버 메모리에서 그 상태 플래그를 NotRun으로 변경하여 프로세스를 일시적으로 정지하려면 bos shutdown 명령을 사용하십시오. BOS 서버 메모리에서 그 상태 플래그를 Run으로 변경하여 정지된 프로세스를 재시작하려면 bos startup 명령을 사용하십시오. 프로세스는 BosConfig 파일의 상태 플래그에 관계없이 시작됩니다. 또한 다음에서 설명하는 것처럼 bos startup 명령을 사용하여 BosConfig 파일에서 상태 플래그가 Run으로 표시된 모든 프로세스를 시작할 수도 있습니다.
bos startup 명령은 BosConfig 파일에서 프로세스의 상태 플래그를 변경하지 않은 채로 프로세스를 시작하므로 프로세스를 영구히 사용 가능하게 하지 않고 검사하는 데 유용합니다. BosConfig 파일에서 그 상태 플래그를 변경하여 프로세스를 정지 및 시작하려면 프로세스 영구 정지 및 시작을 참조하십시오. 프로세스를 정지했다가 즉시 재시작하려면 프로세스를 정지한 후 즉시 재시작하기를 참조하십시오.
| 주: | 모든 시스템의 데이터베이스 서버 프로세스를 한 번에 일시적으로 정지하지 마십시오. 이렇게 하면 데이터베이스를 완전히 사용하지 못하게 될 수 있습니다. |
% bos listusers <machine name>
% bos shutdown <machine name> [<instances>+] [-wait]
여기서
% bos listusers <machine name>
% bos startup <machine name>
여기서
% bos listusers <machine name>
% bos startup <machine name> <instances>+
여기서
기본적으로 BOS 서버가 매일 새로 설치된 2진 파일을 확인하고 연관된 프로세스를 재시작한다고 해도 때때로 프로세스를 정지했다가 즉시 재시작해야 하는 경우가 있습니다. bos restart 명령은 이 기능을 제공하여 영향 받는 각 프로세스의 완전히 새로운 인스턴스를 시작합니다.
프로세스를 재시작하면 서비스 작동 중단 상태가 발생합니다. 보통 시스템이 별로 사용되고 있지 않을 때 재시작하도록 계획하는 것이 가장 바람직합니다. BOS 서버는 일주일에 한 번 모든 프로세스를 자동으로 재시작하여 확장된 시간 동안 프로세스가 실행될 때 발생할 수 있는 중요한 누출 가능성을 줄입니다. BOS 서버의 재시작 시간 설정을 참조하십시오.
% bos listusers <machine name>
% bos restart <machine name> -bosserver
여기서
% bos listusers <machine name>
% bos restart <machine name> -all
여기서
% bos listusers <machine name>
% bos restart <machine name> <instances>+
여기서
기본적으로 BOS 서버는 한 주에 한 번 재시작하고 새 인스턴스는 로컬 /usr/afs/local/BosConfig 파일에서 상태 플래그가 Run으로 설정된 모든 프로세스를 재시작합니다(이것은 -bosserver 플래그를 사용하여 bos restart 명령을 실행하는 것과 동일함). 기본 재시작 시간은 일요일 새벽 3시입니다. 주별 재시작은 중요한 누출을 최소화하도록 디자인됩니다. 중요한 누출 상태는 프로세스가 계속 가상 메모리를 할당하지만 다시 사용 가능 상태로 만들지 않는 경우로 발전할 수 있습니다. 메모리가 완전히 고갈될 때 시스템은 더 이상 제대로 기능하지 못합니다.
또한 BOS 서버는 기본적으로 새로 설치한 2진 파일을 하루에 한 번 확인합니다. /usr/afs/bin 디렉토리의 프로세스 2진 파일에 있는 수정 시간 소인이 프로세스가 마지막으로 시작된 시간보다 더 최근이라는 사실이 발견되면 새 인스턴스가 새로운 2진 파일을 사용하도록 프로세스를 재시작합니다. 기본 2진 파일 확인 시간은 새벽 5시입니다.
재시작을 수행할 경우 파일 시스템이 액세스할 수 없는 동안 작동 중지 상태가 발생할 수 있으므로 기본 재시작 시간은 사용도가 가장 낮을 것으로 예상되는 이른 아침 시간입니다. 데이터베이스 서버 시스템에서 데이터베이스 서버 프로세스를 재시작하면 보통 짧은 시간 동안 모든 사람이 전체 시스템을 사용할 수 없게 되지만 다른 유형의 프로세스를 재시작하면 해당 시스템의 해당 프로세스와 상호 작용하는 사용자만 편리함을 겪게 됩니다. 가장 긴 작동 중단 상태는 보통 파일 서버가 모든 볼륨을 재접속하게 되는 fs 프로세스 재시작의 경우가 됩니다.
각 파일 서버 시스템의 BosConfig 파일은 두 번의 재시작 시간을 기록합니다. 현재 설정을 표시하려면 bos getrestart 명령을 실행하십시오. 시간을 재설정하려면 bos setrestart 명령을 사용하십시오.
% bos getrestart <machine name>
여기서
% bos listusers <machine name>
% bos setrestart <machine name> "<time to restart server>" [-general] [-newbinary]
여기서
원하는 경우 문자열 every 또는 at을 시간 또는 요일 및 시간 정의 앞에 사용하십시오. 이들 단어는 의미를 변경하지는 않으나 bos getrestart 명령의 출력을 보다 이해하기 쉽게 해 줍니다.
| 주: | 지정된 시간이 현재 시간에서 한 시간 이내이면 BOS 서버는 적절한 다음 시간(다음 날의 해당 시간이나 다음 주의 해당 요일과 시간)이 될 때까지 재시작을 수행하지 않습니다. |
각 파일 서버 시스템의 /usr/afs/logs 디렉토리에는 일부 AFS 서버 프로세스의 정상 작동 중에 발생하는 중요한 이벤트를 상세히 설명하는 로그 파일이 들어 있습니다. 로그 파일의 자체 설명 정보는 프로세스 실패 및 다른 문제점을 평가할 때 매우 도움이 될 수 있습니다. 원격에서 로그 파일을 표시하려면 bos getlog 명령을 실행하십시오. 또한 서버 시스템으로 연결하여 문서 편집기나 다른 파일 표시 프로그램(예: cat 명령)을 사용할 수 있습니다.
| 주: | 로그 파일은 주기적으로 데이터베이스 서버 프로세스를 종료했다가 재시작하지 않으면 관리할 수 없을 만큼 커질 수 있습니다(예를 들어 일반 재시작 시간을 사용 불가능하게 한 경우). 이 경우 주기적으로 UNIX rm 명령을 실행하여 현재 로그 파일을 삭제하는 것이 좋은 방법입니다. 서버 프로세스는 필요할 때 자동으로 새 로그 파일을 작성합니다. |
% bos listusers <machine name>
% bos getlog <machine name> <log file to examine>
여기서
전체 또는 상대 경로 이름을 제공하여 다른 디렉토리의 파일을 표시할 수 있습니다. 상대 경로 이름은 /usr/afs/logs 디렉토리에 상대적으로 해석됩니다.