이젠 프로세스와 스레드, 자원 등을 살펴보면서 실습을 진행할 예정이다. 파일시스템의 구조를 알아봤다면 이제 시스템이 어떤 식으로 돌아가고 있는지 볼 차례다. 간단한 기본 명령어부터 해본다
ps - 프로세스 상태를 확인하는 명령어
주로 전통적인 BSD 스타일의 ps aux나 현대 리눅스에서 자주 쓰이는 ps -ef 들을 많이 사용하는 듯 하다 출력 화면과 상세 내용은 조금씩 다르니 취향에 맞게 상황껏 쓰면 된다. 둘 다 공통적으로 전체 프로세스 목록을 볼 수 있고 파이프라인 명령어로 grep 과 같이 거의 세트로 쓰인다. -ef는 부모 자식 ID를 알 수 있고 aux는 메모리와 cpu 사용률을 알 수 있다.
[root@Alma ~]# ps aux | grep net
root 7 0.0 0.0 0 0 ? I< 11:15 0:00 [kworker/R-netns]
root 56 0.0 0.0 0 0 ? I< 11:15 0:00 [kworker/R-inet_]
root 6073 0.0 0.0 3876 2048 pts/0 S+ 12:37 0:00 grep --color=auto net
[root@Alma ~]# ps -ef | grep net
root 7 2 0 11:15 ? 00:00:00 [kworker/R-netns]
root 56 2 0 11:15 ? 00:00:00 [kworker/R-inet_]
root 6075 5249 0 12:37 pts/0 00:00:00 grep --color=auto net| 출력 필드 | 설명(ps aux) |
| USER | 프로세스 소유자의 이름 |
| PID | 프로세스 ID (고유 번호) |
| %CPU | 프로세스가 사용 중인 CPU 시간 비율 (실행된 순간의 스냅샷) |
| %MEM | 프로세스가 사용 중인 물리 메모리 비율 |
| VSZ | 가상 메모리 크기 (KB) |
| RSS | 실제 사용 중인 물리 메모리 크기 (KB) |
| STAT | 프로세스 상태 (R: 실행, S: 대기, Z: 좀비 등) |
| START | 프로세스가 시작된 시간/날짜 |
| TIME | 프로세스가 누적 사용한 CPU 시간 |
| COMMAND | 실행된 명령어와 인자 |
| 출력 필드 | 설명(ps -ef) |
| UID | 프로세스 소유자의 숫자 ID |
| PID | 프로세스 ID |
| PPID | 부모 프로세스 ID (어느 프로세스가 이 프로세스를 시작했는지) |
| C | CPU 사용률 (SysV 스타일의 %CPU) |
| STIME | 프로세스가 시작된 시간 |
| TTY | 프로세스가 연결된 터미널 |
| TIME | 프로세스가 누적 사용한 CPU 시간 |
| CMD | 실행된 명령어와 인자 |
f 옵션 대신 o 옵션으로 필드를 직접 구성할 수도 있고 --sort로 필드를 지정하면 그 필드를 기준으로 정렬을 시켜 보기 편하게 할 수도 있다. 또 H를 쓰면 계층 구조로 어떤 프로세스로부터 내려오는지 파악도 가능
[root@Alma ~]# ps -eo %mem,cmd,ppid --sort %mem | grep system
0.0 grep --color=auto system 5249
0.2 /usr/lib/systemd/systemd-jo 1
0.2 /usr/lib/systemd/systemd-lo 1
0.3 /usr/lib/systemd/systemd-ud 1
0.3 /usr/lib/systemd/systemd -- 1
0.4 /usr/lib/systemd/systemd -- 0
[root@Alma ~]# ps -efH | grep system
root 1 0 0 11:15 ? 00:00:01 /usr/lib/systemd/systemd --switched-root --system --deserialize 31
root 648 1 0 11:15 ? 00:00:00 /usr/lib/systemd/systemd-journald
root 664 1 0 11:15 ? 00:00:00 /usr/lib/systemd/systemd-udevd
dbus 822 1 0 11:15 ? 00:00:00 /usr/bin/dbus-broker-launch --scope system --audit
root 829 1 0 11:15 ? 00:00:00 /usr/lib/systemd/systemd-logind
root 6251 5249 0 13:01 pts/0 00:00:00 grep --color=auto system
root 5202 1 0 11:16 ? 00:00:00 /usr/lib/systemd/systemd --user
Top - 프로세스 상태를 모니터링하는 도구
이제 간단히 프로세스를 출력해봤으면 실시간으로 프로세스들을 보면 된다. top이랑 htop이 있다.
[root@Alma ~]# top
top - 13:07:45 up 1:52, 2 users, load average: 0.00, 0.00, 0.00
Tasks: 149 total, 1 running, 148 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 13.7/3654.1 [||||||||||||| ]
MiB Swap: 0.0/4040.0 [ ]
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 173920 16632 10752 S 0.0 0.4 0:01.13 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pool_workqueue_
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-rcu_g
5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-sync_
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-slub_
7 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-netns
9 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-events_highpri
11 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-mm_pe
13 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_kthre
14 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_rude_
15 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_trace
16 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
17 root 20 0 0 0 0 I 0.0 0.0 0:00.28 rcu_preempt
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_exp_par_gp_입력하자마자 이런 화면이 뜨고 계속해서 바뀌는 게 보인다. p랑 m를 누르면 각각 cpu와 메모리 사용량 기준으로 정렬을 시켜준다. k를 누르고 프로세스를 죽일 수도 있다. r은 프로세스의 우선순위 변경이 가능하고 q를 누르면 나가진다.
다음으로는 htop이다 이건 기본적으로 없으니 dnf로 깔아줘야 함. 기능은 top보다도 많고 보기도 편하다. 친절하게 펑션키로 뭘 할 수 있는지 다 알려준다 단축키로도 가능, 궁금하면 h눌러서 단축키 확인 필터링, 검색도 가
근데 프로세스 상태 확인을 한다는 건 알겠는데, 변화가 보이지 않는다 당연히 아무것도 추가로 한 게 없으니까 그렇다. 간단한 코드 짜서 무한루프를 돌려 메모리를 먹게 해본다. 쉘 스크립트도 있지만 파이썬이 내장되어 있기 때문에 간단하게 바로 짜서 실행시킬 수 있는 파이썬을 사용해 메모리 먹는 하마 코드를 작성해 돌려보면 될 것이다.
[root@Alma ~]# vi main.py
import time
def loop(count):
str = "안녕?"
while(True):
print(str, count)
count += 1
str += str
time.sleep(1)
def __main__():
count = 1
loop(count)
__main__()[root@Alma ~]# python3 main.py
안녕? 1
안녕?안녕? 2
안녕?안녕?안녕?안녕? 3
안녕?안녕?안녕?안녕?안녕?안녕?안녕?안녕? 4
안녕?안녕?안녕?안녕?안녕?안녕?안녕?안녕?안녕?안녕?안녕?안녕?안녕?안녕?안녕?안녕? 5원하는대로 문자열이 제곱으로 늘어나서 출력된다. 메모리가 많이 먹을 것이다 그럼 모니터링을 해보자.
출력되는 게 거슬리니 일단 안 보이게 돌리고 htop으로 모니터링할 수 있게 백그라운드로 실행시켜 놓자.
[root@Alma ~]# python3 main.py > /dev/null &
역시 제곱으로 설정해서 그런지 처음엔 미동도 없다가 조금씩 오르더니 갑자기 팍 치솟아 스왑영역까지 침범해버렸다.
내 노트북이 이상해지는 건 용납못하니 바로 kill %1으로 백그라운드에 돌아가는 작업을 죽였다.
이렇게 프로세스 자원 사용량 모니터링을 간단하게 하고 프로세스를 끄는 실습을 해봤다. 이제 프로세스 조작을 하자.
nice, renice - 프로세스의 우선 순위를 변경하는 명령어
앞서 ps -ef로 보았듯 엄청나게 많은 프로세스가 시스템 위에 존재하는 걸 확인할 수 있었다.
근데, cpu가 아무리 좋다고 해도 이 모든걸 동시에 실행시킬 수는 없다. 그래서 프로세스는 스케줄링으로 관리된다.
사람이 볼 때는 매우 빨라 여러 개가 동시에 돌아가는 것처럼 보이지만
사실은 시간을 아주 잘게 쪼개서 돌아가면서 작업시키는 거라 볼 수 있겠다.
그래서 프로세스에도 순서가 있는데, 이걸 강제로 조정할 수 있는 것이 nice 명령어인 것이다.
사람이 nice하다고 하면 그 사람은 좋은 사람이라고 하는 것처럼 숫자가 높으면 이 프로세스는 매우 친절한 프로세스이다.
이 말은 즉, 친절하기 때문에 배려를 잘하니까 우선순위가 밀리게 되고 반대로 음수로 가게 되면 nice가 아니라 bad하다고 생각하면 편하다.
이번엔 셸 스크립트로 작성해 돌려본다. 이번엔 제곱 말고 그냥 실행시켜서 빠르지만 일정하게 자원을 먹도록 한다.
마찬가지로 백그라운드로 실행, 카운트랑 슬립을 적절히 조절해서 cpu 사용률을 조절한다
[root@Alma ~]# vi script.sh
#!/bin/bash
echo "===== 스크립트 실행 시~작! ====="
i=1
j=1
k=1
while true; do
for count in $(seq 1 10000); do
i=$((i + 1))
j=$((j + 1))
k=$((k + 1))
done
sleep 0.01
done
[root@Alma ~]# chmod +x script.sh
[root@Alma ~]# ./script.sh &
[root@Alma ~]# ./script.sh &경쟁시키고 우선순위 조정하기 위해 2번 돌린다. 맨 처음 sleep 제한 없이 돌렸다가 거의 100퍼 찍어서 조절함;
여기 cpu 사용률 기준 정렬하여 보면 아까 2개 스크립트가 cpu를 신나게 잡아먹는 게 보인다. 똑같으니까 서로 엎치락 뒤치락 난리 났다.
각각의 PID를 가져와서 renice로 조절해본다. 값은 -20~19까지 줄 수 있다. 하나는 낮게 하나는 높게 줘보자.
지금은 멀티 코어라 코어를 제한해서 경쟁시켜야 확인이 가능하기에 이 2개의 프로세스들은 코어를 제한한다.
[root@Alma ~]# ps -ef | grep script
root 48984 5249 72 14:28 pts/0 00:03:56 /bin/bash ./script.sh
root 49430 5249 72 14:28 pts/0 00:03:47 /bin/bash ./script.sh
root 76084 5249 0 14:33 pts/0 00:00:00 grep --color=auto script
[root@Alma ~]# renice 10 48984
48984 (process ID) old priority 0, new priority 10
[root@Alma ~]# renice -10 49430
49430 (process ID) old priority 0, new priority -10
[root@Alma ~]# taskset -pc 0 48984
pid 48984's current affinity list: 0-5
pid 48984's new affinity list: 0
[root@Alma ~]# taskset -pc 0 49430
pid 49430's current affinity list: 0-5
pid 49430's new affinity list: 0
NI값이 nice한 정도인데 이정도 차이가 난다. 이 값의 차이가 적을 수록 사용률도 비슷하고, 차이가 크면 차이가 크게 난다고 한다.
그럼 다시 프로세스를 종료하고 이번엔 nice로 값의 차이가 적게 줘본다.
[root@Alma ~]# nice -n 0 ./script.sh &
===== 스크립트 실행 시~작! =====
[3] 132109
[root@Alma ~]# nice -n 1 ./script.sh &
===== 스크립트 실행 시~작! =====
[4] 132255
[root@Alma ~]# taskset -pc 0 132109
pid 132109's current affinity list: 0-5
pid 132109's new affinity list: 0
[root@Alma ~]# taskset -pc 0 132255
pid 132255's current affinity list: 0-5
pid 132255's new affinity list: 0
[root@Alma ~]# htop
nice 명령어는 프로세스를 실행하기 전에 미리 값을 정해주고, renice는 이미 실행된 프로세스의 값을 변경하는 차이가 있다.
fg, bg - 프로세스 실행 위치를 정하는 명령어
앞서 프로세스의 상태를 확인하기 위해 실행을 다 백그라운드로 돌려서 했었다 이 때 프롬프트 맨 마지막에 &를 붙이면
백그라운드 작업이 된 걸 알 수 있었다. 그리고 백그라운드의 작업은 jobs 명령어로 확인할 수가 있었다.
또, ps -ef 등에서도 나오긴 하는데 바로 찾기가 그리 편하진 않다.
아무튼 백그라운드에 가있는 작업은 PID와는 다르게 작업 번호가 있는데, %1, %2 등으로 조작이 가능하다.
이걸 다시 앞으로 끄집어내려면 fg 명령어를 쓰면 된다 백 -> 포그라운드로 바뀜
[root@Alma ~]# ./script.sh &
[1] 235818
[root@Alma ~]# ===== 스크립트 실행 시~작! =====
안녕 10001
안녕 20001
안녕 30001
ls안녕 40001
a.out anaconda-ks.cfg main.c main.py script.sh veeam-recovery-amd64-6.0.0.iso
[root@Alma ~]# pwd
/root백그라운드로 가있으면 터미널에서 작업을 그대로 할 수 있다. 실제 도는지 확인하기 위해 echo 명령을 추가하였다. fg %1으로 앞으로 빼면 해당 세션에서 작업이 불가하다. 그러므로 다시 bg %1해도 안 먹힌다. 먹게 하기 위해선 ctrl+z 키로 일시 중단한 다음 bg %1로 다시 뒤로 빼면 된다.
kill, killall, pkill - 프로세스를 제어하는 명령어
이번엔 시그널에 대해 알아보자. 프로세스가 제어될 때는 신호에 의해 제어가 된다. 실습을 위해 다시 프로세스를 만든다.
여기서 /dev/null은 표준 출력을 안 뜨도록 하는 특수한 장치?이다. >표시는 리다이렉션이니 왼쪽의 결과를 오른쪽으로 가게 하고, null은 아무것도 없는 것이니 출력이 없어진다고 보면 된다.
| >/dev/null | 표준 출력, 파일 디스크립터를 리눅스 커널의 블랙홀 장치인 /dev/null로 보냄 화면에 출력이 안 나타내게 함 |
| 2>/dev/null | 표준 에러, 파일 디스크립터를 /dev/null로 보냄 에러 메시지를 화면에 출력되지 않게 함 |
| 2>&1 | 표준 에러를 표준 출력이 리다이렉션되는 곳과 동일한 곳으로 보 예) cmd >file 2>&1은 출력과 에러를 모두 file로 보냄 |
[root@Alma ~]# ./script.sh >/dev/null &
[1] 236187
[root@Alma ~]# ./script.sh >/dev/null &
[2] 236190
[root@Alma ~]# ./script.sh >/dev/null &
[3] 236193
[root@Alma ~]# ./script.sh >/dev/null &
[4] 236198
[root@Alma ~]# jobs
[1] Running ./script.sh > /dev/null &
[2] Running ./script.sh > /dev/null &
[3]- Running ./script.sh > /dev/null &
[4]+ Running ./script.sh > /dev/null &이제 프로세스들을 하나씩 제어해보자. 우선 죽여본다. jobs는 백그라운드 작업 목록이 보이는 것이라 했다.
사실 엄밀히 말하자면 kill은 죽이는 명령어라기보다 신호를 통해서 제어를 할 수 있어 그 중 죽이는 게 포함된다 보는 게 맞을 거다.
암튼 얘들은 특수하게 %1...n으로 kill 명령을 통해 없앨 수 있다. 예시를 보겠다.
[root@Alma ~]# kill %4
[root@Alma ~]# jobs
[1] Running ./script.sh > /dev/null &
[2] Running ./script.sh > /dev/null &
[3] Running ./script.sh > /dev/null &
[4]- Terminated ./script.sh > /dev/null
[5]+ Running ./script.sh > /dev/null &
[root@Alma ~]# kill %1 %2 %3
[root@Alma ~]# jobs
[1] Terminated ./script.sh > /dev/null
[2] Terminated ./script.sh > /dev/null
[3]- Terminated ./script.sh > /dev/null
[5]+ Running ./script.sh > /dev/null &
[root@Alma ~]# jobs
[5]+ Running ./script.sh > /dev/null &이렇게 여러개를 같이 지정해서 지울 수도 있고 지우고 나서 다시 jobs를 확인하면 상태가 뜨고 사라진다.
다른 작업이 사라져도 살아있는 작업의 번호는 유지된다.
kill은 작업ID 말고 PID로도 제어가 가능하다. 단순히 죽이는 게 아니라 신호를 주는 거니 이걸 kill -l로 확인이 가능하다.
매우 많은데, Ctrl + z, c 단축키도 이 시그널 중에 포함된다. 1번은 프로세스를 리로드, 2번은 ctrl c와 같고 20번은 ctrl z와 같다.
[root@Alma ~]# kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) SIGRTMAX-1 64) SIGRTMAX가장 흔하고 기본적으로 쓰이는 게 9번과 15번의 SIGKILL, SIGTERM이다. 둘 다 프로세스를 종료시킬 때 사용함
하지만 가급적 9번으로 쓰지 말자. 어차피 기본값이 15번이라 정상적으로 모든 작업을 마무리한 다음 끄도록 하지만 특정 상황으로 인해
이상이 발생할 경우 불가피하게 강제종료를 시켜야 할 수도 있는데, 중요한 데이터 작업이 일어나는 프로세스면 곧바로 끄지 말도록 하자.
PID를 이용해 작업을 종료하는 모습. 시그널을 지정을 할 땐 이렇게! 기본값이 15다.
[root@Alma ~]# ps -ef | grep script
root 236611 5249 0 15:28 pts/0 00:00:00 /bin/bash ./script.sh
root 239223 5249 0 15:49 pts/0 00:00:00 grep --color=auto script
[root@Alma ~]# kill -15 236611
[root@Alma ~]# jobs
[5]+ Terminated ./script.sh > /dev/nullPID말고 작업이름으로 종료시키고 싶다면? killall, pkill을 이용, 킬올은 전체가 일치해야 종료, pkill은 포함이면 싹 종료다.
만약 script를 지우려는데 귀찮아서 pkill s로 지운다면? ssh 같은 것도 날라가니 주의
[root@Alma ~]# ps -ef | grep script
root 239244 5249 0 15:51 pts/0 00:00:00 /bin/bash ./script.sh
root 239246 5249 0 15:51 pts/0 00:00:00 /bin/bash ./script.sh
root 239249 5249 0 15:51 pts/0 00:00:00 /bin/bash ./script.sh
root 239251 5249 0 15:51 pts/0 00:00:00 /bin/bash ./script.sh
root 239254 5249 0 15:51 pts/0 00:00:00 /bin/bash ./script.sh
root 239258 5249 0 15:51 pts/0 00:00:00 /bin/bash ./script.sh
root 239261 5249 0 15:51 pts/0 00:00:00 /bin/bash ./script.sh
root 239306 5249 0 15:51 pts/0 00:00:00 grep --color=auto script
[root@Alma ~]# killall script
script: no process found
[root@Alma ~]# killall script.sh
[1] Terminated ./script.sh > /dev/null
[2] Terminated ./script.sh > /dev/null
[3] Terminated ./script.sh > /dev/null
[4] Terminated ./script.sh > /dev/null
[5] Terminated ./script.sh > /dev/null
[6]- Terminated ./script.sh > /dev/null
[7]+ Terminated ./script.sh > /dev/null
[root@Alma ~]# ps -ef | grep script
root 239395 5249 0 15:52 pts/0 00:00:00 /bin/bash ./script.sh
root 239397 5249 0 15:52 pts/0 00:00:00 /bin/bash ./script.sh
root 239399 5249 0 15:52 pts/0 00:00:00 /bin/bash ./script.sh
root 239402 5249 0 15:52 pts/0 00:00:00 /bin/bash ./script.sh
root 239405 5249 0 15:52 pts/0 00:00:00 /bin/bash ./script.sh
root 239407 5249 0 15:52 pts/0 00:00:00 /bin/bash ./script.sh
root 239414 5249 0 15:52 pts/0 00:00:00 /bin/bash ./script.sh
root 239450 5249 0 15:52 pts/0 00:00:00 grep --color=auto script
[root@Alma ~]# pkill script
[1] Terminated ./script.sh > /dev/null
[2] Terminated ./script.sh > /dev/null
[3] Terminated ./script.sh > /dev/null
[4] Terminated ./script.sh > /dev/null
[5] Terminated ./script.sh > /dev/null
[6]- Terminated ./script.sh > /dev/null이번엔 프로세스 밑 스레드 확인을 해보자. 프로세스는 안에 또 여러개의 스레드로 구성된다.
프로세스가 조금 더 크고 스레드는 작은 작업 단위라고 보면 되는데, 특징으로는 이런 게 있다.
프로세스는 프로세스들끼리 독립적이라 여러 개가 동시 실행이 어려운데, 스레드는 한 프로세스 내에 여러 개가 프로세스의 자원을 지들끼리 나눠 사용하며 병렬적으로 동시 작업 수행이 가능한 점이 있다.
현대 들어 CPU 코어가 여러 개로 늘어난 이후로는 프로세스도 병렬처리가 가능하게 되었다.
그래서 크롬 같은 브라우저에서는 탭마다 독립적인 프로세스가 실행되어 돌아가서 안정성이 높아졌다.
이전 인터넷 익스플로어 때는 탭마다 스레드로 처리하여서 하나가 맛이가면 전체 프로세스인 브라우저 자체가 맛이 갔었다고 한다.
하지만 이렇기 때문에 사용하는 입장에선 편리하지만 컴퓨터는 자원 소모가 많아져 힘들 것이다.
[root@Alma ~]# ps -efL | grep proxy
root 877 1 877 0 6 11:15 ? 00:00:00 /usr/sbin/gssproxy -D
root 877 1 880 0 6 11:15 ? 00:00:00 /usr/sbin/gssproxy -D
root 877 1 881 0 6 11:15 ? 00:00:00 /usr/sbin/gssproxy -D
root 877 1 882 0 6 11:15 ? 00:00:00 /usr/sbin/gssproxy -D
root 877 1 883 0 6 11:15 ? 00:00:00 /usr/sbin/gssproxy -D
root 877 1 884 0 6 11:15 ? 00:00:00 /usr/sbin/gssproxy -D
root 239517 5249 239517 0 1 15:59 pts/0 00:00:00 grep --color=auto proxy
[root@Alma ~]# ps -ef | grep proxy
root 877 1 0 11:15 ? 00:00:00 /usr/sbin/gssproxy -D
root 239519 5249 0 15:59 pts/0 00:00:00 grep --color=auto proxy
'리눅스 > 실습' 카테고리의 다른 글
| 워드프레스 LEMP 서버 구축하기-2 (0) | 2025.11.08 |
|---|---|
| 워드프레스 LEMP 서버 구축하기-1 (0) | 2025.11.07 |
| 리눅스 실습(3) - 파일시스템 실습(백업 마무리) (0) | 2025.11.02 |
| 리눅스 실습(3) - 파일시스템 실습(백업 스케쥴링과 이중화) (0) | 2025.11.01 |
| 리눅스 실습(3) - 파일시스템 실습(시스템 백업) (0) | 2025.11.01 |