master (PID 14452, USER=root) + worker 4 개 (USER=www-data, PPID=14452). 모두 master 가 fork 한 자식. PPID 컬럼이 그 관계를 보여줌.
왜 권한이 다른가 — 80/443 같은 1024 미만 포트는 root 만 bind 가능 (전통적 Unix). 그래서 master 가 root 로 시작 → 포트 bind → worker fork → worker 는 www-data 로 권한 강등(setuid). 보안 best practice = 실제 요청 처리는 비특권 user.
STAT=Ss master 의 s = session leader. worker 는 S (sleeping, idle).
RSS 비교 — master 2388K vs worker 각 4844K. worker 가 실제 작업 코드·연결 상태를 들고 있어서 더 큼.
TTY=? = 데몬이라 터미널 없음. grep 자신만 pts/1 (내 셸).
마지막 grep --color=auto nginx 줄 = grep 명령이 자기 자신을 잡음. 매번 보임. 위 트릭 (grep "[n]ginx") 으로 회피 가능.
USER=www-data 와 파일 권한의 user/group/other 관계 → 자세한 건 04. Linux Permissions 노트 참고.
su # root 계정으로 전환su -l # root 계정으로 전환 + 사용자 환경 및 작업 디렉터리 변경su <username> # username 계정으로 전환su -l <username> # username 계정으로 전환 + 사용자 환경 및 작업 디렉터리 변경su -c 'ls -l /root' # root 계정으로 명령어 실행
substitute user, 특정 사용자로 전환하는 명령
해당 사용자의 비밀번호를 알아야 실행 가능
root 로 실행 시 타깃 사용자의 비밀번호를 몰라도 됨
옵션
default : 사용자만 변경
-l / --login : 지정된 계정으로 로그인 셸을 실행, 환경변수를 초기화하고(HOMESHELLUSERLOGNAMEPATH) 해당 계정의 홈 디렉터리로 이동
-c / --command : 셸 명령어 1개만 실행하고 종료, 대상 사용자(생략 시 root)의 암호가 필요
sudo
sudo [-u username] command # username 계정으로 명령 실행sudo command # root 계정으로 명령 실행# /etc/sudoers...# User privilege specificationroot ALL=(ALL:ALL) ALL# Members of the admin group may gain root privileges%admin ALL=(ALL) ALL# Allow members of group sudo to execute any command%sudo ALL=(ALL:ALL) ALL# See sudoers(5) for more information on "@include" directives:@includedir /etc/sudoers.d
root 또는 다른 사용자로 명령 실행
su 명령과 달리 본인의 암호만 필요, root 혹은 다른 사용자의 비밀번호를 몰라도 됨
단, 관리자가 /etc/sudoers 파일에 권한을 설정해둬야 함
프로세스·시스템 (자세히 = 06. Linux Processes & Systemd)
명령
설명
예시
ps
프로세스 목록
ps aux, ps -ef
kill
시그널 전송 (기본 SIGTERM=15)
kill <pid>, kill -9 <pid>
top
실시간 프로세스·자원 모니터
top
free
메모리 사용량
free -h
uptime
가동 시간 + load average
uptime
systemctl
systemd 서비스 제어
systemctl start nginx
journalctl
systemd 로그 조회
journalctl -u nginx -f
디스크·파일시스템 (자세히 = 05. Linux Filesystem)
명령
설명
예시
df
파일시스템별 디스크 사용량
df -h
du
디렉터리 크기
du -sh dir/
mount / umount
파일시스템 마운트·언마운트
mount /dev/sdb1 /mnt, umount /mnt
lsblk
블록 디바이스 목록 (트리)
lsblk
fdisk
파티션 관리
sudo fdisk /dev/sdb
mount
# mount -t [파일 시스템 종류] [마운트 할 장치 파티션] [마운트할 위치]blkid | grep /dev/sdb1mkfs.ext4 /dev/sdb1 # /dev/sdb1 파티션을 ext4 파일 시스템으로 포맷blkid | grep /dev/sdb1mount -t ext4 /dev/sdb1 /mpdf -h# umount [마운트 위치]fuser /mpumount /mp # 마운트 해제df -h
mount 란 포맷이 완료된 파티션을 사용자들이 직접 접근할 수 있도록 디렉터리와 연결하는 과정
mount 명령, /etc/mtab 파일, /proc/mounts 파일로 마운트 정보를 확인할 수 있음
최근 배포판은 /etc/mtab 이 /proc/self/mounts 심볼릭 링크라 둘의 내용은 같고, mount 명령은 같은 정보를 다른 형식으로 보여줌
/etc/fstab
# /etc/fstab# 파일 시스템 장치 | 마운트 포인트 | 파일 시스템 | 옵션 | 덤프 | 파일 체크LABEL=cloudimg-rootfs / ext4 discard,commit=30,errors=remount-ro 0 1LABEL=BOOT /boot ext4 defaults 0 2LABEL=UEFI /boot/efi vfat umask=0077 0 1mount0 /Users/meatsby virtiofs ro,nofail,comment=cloudconfig 0 0# /etc/fstab 수정 적용mount -a
/dev/tcp/HOST/PORT = 실제 파일이 아니라 bash 내장 기능. 이 경로로 리다이렉션을 여는 순간 bash 가 HOST:PORT 로 TCP connect() 를 시도한다.
cat < /dev/null > /dev/tcp/github.com/22 = /dev/null 의 stdin (빈 입력)을 < 으로 전달하고 cat 에서 나온 stdout 을 > 로 전달하여 /dev/tcp/github.com/22 소켓에 쓴다. 실제 데이터 전송이 목적이 아니라, 리다이렉션을 여는 행위 자체로 연결 성공 여부만 확인하는 트릭.
nc -z host port 와 동일한 역할을 외부 바이너리 없이 수행.
bash -c '...' 로 새 bash 를 띄우는 이유 = timeout은 “명령 + 인자” 하나만 실행시키는 구조라, 리다이렉션이 섞인 복합 구문(cat < ... > ...)을 직접 못 받는다. bash -c로 감싸서 전체 구문을 새 셸이 통째로 해석하게 만들고, timeout은 그 bash 프로세스 하나만 감시한다.
timeout 5 = 방화벽이 SYN 을 그냥 drop 하면 연결 시도가 무한 대기할 수 있어 5초 후 강제 종료.
2>/dev/null && echo "OK" || echo "FAIL"
>(1>)는 stdout 만, 2>는 stderr 만 리다이렉트, 서로 다른 파일 디스크립터(FD)
2>/dev/null은 연결 실패 시 bash 가 내는 에러 메시지(bash: connect: Connection refused 등)만 버리고, > /dev/tcp/...로 이미 지정된 stdout 에는 영향 없음.
&&/||는 출력 유무가 아니라 exit code로 갈린다. timeout 5 bash -c '...'는 2>/dev/null, > /dev/tcp/... 때문에 화면에 아무것도 안 찍지만, 연결 성공 시 exit code 0(&& 발동 → OK), 실패·타임아웃 시 exit code ≠ 0(|| 발동 → FAIL)으로 분기한다.