Linux 면접 질문

"현재 작업 디렉토리를 확인하는 명령어는 pwd입니다. 'Print Working Directory'의 약자이고요. 이 명령어는 현재 제가 어느 디렉토리에 있는지, 즉 절대 경로를 알려줍니다.

pwd가 필요한 상황은 여러 가지가 있습니다. 예를 들어, 복잡한 파일 시스템에서 작업할 때 현재 위치를 잊어버렸을 경우, pwd를 통해 정확한 위치를 파악할 수 있습니다.

또 다른 예로는 스크립트를 실행할 때입니다. 스크립트 내에서 상대 경로를 사용하여 파일을 참조하는 경우, 스크립트가 실행되는 위치에 따라 파일이 제대로 찾아지지 않을 수 있습니다. 이때 pwd를 사용하여 스크립트가 실행되는 위치를 확인하고, 상대 경로를 수정하거나 절대 경로를 사용하는 방식으로 문제를 해결할 수 있습니다."

chmod 명령어는 Linux에서 파일이나 디렉토리의 접근 권한을 변경하는 데 사용됩니다. 가장 일반적인 방법은 숫자를 이용하는 것인데, 각 숫자는 소유자, 그룹, 기타 사용자에 대한 읽기(r), 쓰기(w), 실행(x) 권한을 나타냅니다.

chmod 755 filename 명령어는 다음과 같은 권한을 부여합니다.

• 소유자 (첫 번째 숫자 7): 읽기(4) + 쓰기(2) + 실행(1) = 7. 소유자는 파일을 읽고, 쓰고, 실행할 수 있습니다.
• 그룹 (두 번째 숫자 5): 읽기(4) + 실행(1) = 5. 그룹 사용자는 파일을 읽고 실행할 수 있습니다.
• 기타 사용자 (세 번째 숫자 5): 읽기(4) + 실행(1) = 5. 기타 사용자도 파일을 읽고 실행할 수 있습니다.

이처럼 chmod 755는 실행 파일이나 스크립트 파일에 일반적으로 적용되는 권한 설정입니다.

Linux에서 현재 실행 중인 프로세스 목록을 확인하는 가장 기본적인 명령어는 ps입니다. ps aux와 같이 옵션을 붙여 사용하면 더 자세한 정보를 볼 수 있습니다. 또한, top 명령어를 사용하면 실시간으로 프로세스 정보를 확인할 수 있습니다.

특정 프로세스의 PID를 찾기 위해서는 ps 명령어의 결과에서 grep을 함께 사용하는 것이 일반적입니다. 예를 들어, 'nginx'라는 프로세스를 찾고 싶다면 ps aux | grep nginx 와 같이 사용할 수 있습니다. 이렇게 찾은 PID를 사용하여 해당 프로세스를 강제 종료하려면 kill 명령어를 사용합니다. kill -9 [PID] 형태로 입력하면 해당 PID를 가진 프로세스를 즉시 종료할 수 있습니다. -9 옵션은 가장 강력한 종료 신호로, 프로세스가 응답하지 않을 때 사용합니다.

쉘 스크립트에서 변수를 선언하고 값을 할당하는 가장 기본적인 방법은 변수명=값 형태로 사용하는 것입니다. 예를 들어 NAME="John" 이라고 하면 NAME이라는 변수에 "John"이라는 문자열이 할당됩니다. 주의할 점은 등호(=) 앞뒤에 공백이 없어야 한다는 것입니다.

변수에 할당된 값을 출력하려면 변수명 앞에 달러 기호($)를 붙여서 사용합니다. echo $NAME 또는 echo ${NAME}과 같이 사용할 수 있습니다. ${NAME} 형태는 변수명 뒤에 바로 다른 문자가 오는 경우 변수명을 명확하게 구분하기 위해 사용하면 좋습니다.

예를 들어, 다음과 같은 스크립트를 실행하면 "John"이 출력됩니다.

NAME="John"
echo $NAME

변수를 export하면 자식 프로세스에서도 해당 변수를 사용할 수 있습니다. export NAME과 같이 사용합니다.

find 명령어는 Linux에서 파일이나 디렉토리를 검색할 때 매우 유용한 도구입니다. 기본적인 사용법은 find [경로] [옵션] 형태로, 지정된 경로에서 특정 조건에 맞는 파일이나 디렉토리를 재귀적으로 찾아줍니다.

경로는 검색을 시작할 디렉토리를 의미하며, 옵션은 검색 조건을 지정합니다. 가장 많이 사용되는 옵션 중 하나는 -name으로, 파일 이름을 기준으로 검색할 때 사용합니다.

예를 들어, 현재 디렉토리와 그 하위 디렉토리에서 'test.txt'라는 이름의 파일을 찾으려면 다음과 같은 명령어를 사용할 수 있습니다.

find . -name test.txt

여기서 .은 현재 디렉토리를 의미하며, -name test.txt는 파일 이름이 'test.txt'인 파일을 찾으라는 조건을 나타냅니다. 이 명령어를 실행하면 현재 디렉토리 및 하위 디렉토리에서 'test.txt' 파일을 찾아 그 경로를 출력해줍니다.

세 명령어 cat, less, more는 모두 Linux에서 파일 내용을 확인하는 데 사용되지만, 동작 방식과 적합한 사용 상황에 차이가 있습니다.

cat은 파일의 전체 내용을 한 번에 출력합니다. 파일이 짧을 때는 편리하지만, 내용이 길면 터미널 화면을 빠르게 스크롤하여 내용을 확인하기 어려울 수 있습니다.

more와 less는 파일을 페이지 단위로 보여줍니다. more는 기본적인 페이지 넘김 기능만 제공하는 반면, less는 페이지 앞/뒤 이동, 검색 등 더 많은 기능을 제공합니다.

대용량 파일을 다룰 때는 less를 사용하는 것이 좋습니다. cat은 파일 전체를 메모리에 로드하려 시도하여 시스템에 부담을 줄 수 있지만, less는 필요한 부분만 읽어와 보여주기 때문에 효율적입니다. 따라서, 짧은 파일은 cat, 긴 파일은 less를 사용하는 것이 일반적입니다. more는 less에 비해 기능이 제한적이므로 특별한 이유가 없다면 less를 사용하는 것이 좋습니다.

sudo 명령어는 일반 사용자가 관리자, 즉 root 권한으로 특정 명령어를 실행할 수 있도록 해주는 아주 유용한 도구입니다.

일반 사용자가 sudo를 사용하면 다음과 같은 이점을 얻을 수 있습니다.

첫째, 보안 강화입니다. root 계정은 시스템의 모든 권한을 가지고 있기 때문에 직접 사용하는 것은 매우 위험합니다. sudo를 사용하면 필요한 명령어에 대해서만 일시적으로 root 권한을 얻을 수 있어, 실수로 시스템을 손상시키거나 악의적인 공격으로부터 시스템을 보호하는 데 도움이 됩니다.

둘째, 접근 제어입니다. 시스템 관리자는 sudoers 파일을 통해 어떤 사용자가 어떤 명령어를 root 권한으로 실행할 수 있는지 세밀하게 제어할 수 있습니다. 이를 통해 특정 사용자에게 필요한 관리자 권한만 부여하여 시스템 운영의 효율성과 보안성을 높일 수 있습니다.

간단히 말해, sudo는 일반 사용자가 꼭 필요한 경우에만 제한적으로 관리자 권한을 안전하게 사용할 수 있게 해주는 핵심적인 명령어입니다.

네, 백그라운드에서 실행 중인 프로세스를 관리하는 방법은 여러 가지가 있습니다. 가장 기본적인 방법은 명령어 뒤에 &를 붙이는 것입니다. 예를 들어 sleep 100 &를 실행하면 sleep 100 프로세스가 백그라운드에서 실행됩니다. 하지만 이 방법은 터미널 세션이 종료되면 프로세스도 함께 종료될 수 있다는 단점이 있습니다.

nohup은 이러한 문제를 해결하기 위해 사용됩니다. nohup command & 형태로 사용하면, 터미널 세션이 종료되더라도 프로세스가 계속 실행됩니다. nohup은 SIGHUP 시그널을 무시하고, 표준 출력과 표준 에러를 기본적으로 nohup.out 파일로 리디렉션합니다.

&는 단순히 프로세스를 백그라운드로 보내는 역할만 하지만, nohup은 프로세스가 터미널 세션 종료에 영향을 받지 않도록 보호하는 역할을 합니다. 예를 들어, 서버에서 장시간 데이터 처리 작업을 실행해야 할 때 nohup을 사용하면 안정적으로 작업을 완료할 수 있습니다.

추가적으로 disown 명령어를 사용하면 이미 백그라운드로 실행 중인 프로세스를 현재 쉘의 작업 목록에서 제거하여, 쉘 종료 시 해당 프로세스가 종료되지 않도록 할 수 있습니다.

"SUID, SGID, Sticky Bit는 Linux 파일 시스템의 특별한 권한 설정입니다.

SUID는 실행 파일 실행 시, 실행하는 사용자 대신 파일 소유자의 권한으로 실행되게 합니다. 예를 들어, passwd 명령은 SUID가 설정되어 있어 일반 사용자가 root 권한으로 암호를 변경할 수 있게 합니다. 하지만 잘못 설정하면 권한 상승 공격에 취약해질 수 있습니다.

SGID는 실행 파일의 경우 그룹 권한으로 실행되게 하고, 디렉토리의 경우 생성되는 파일의 그룹을 디렉토리의 그룹으로 설정합니다. 공동 작업 환경에서 유용하지만, 역시 남용하면 보안 문제가 발생할 수 있습니다.

Sticky Bit는 디렉토리에 설정하면, 해당 디렉토리 내의 파일 삭제 권한을 파일 소유자, 디렉토리 소유자, root 사용자에게만 부여합니다. 공용 디렉토리(/tmp)에서 다른 사용자의 파일 삭제를 방지하는 데 사용됩니다.

이러한 권한들은 편리하지만, 최소 권한 원칙에 따라 신중하게 사용해야 합니다. 불필요한 SUID/SGID 설정은 제거하고, Sticky Bit는 필요한 경우에만 적용해야 합니다."

네, Linux에서 하드 링크와 심볼릭 링크의 차이점을 설명드리겠습니다.

하드 링크는 쉽게 말해 '또 다른 이름'입니다. 같은 inode를 공유하기 때문에, 원본 파일과 완전히 동일한 파일로 취급됩니다. inode는 파일 시스템에서 파일의 메타데이터(소유자, 권한, 데이터 블록 위치 등)를 담고 있는 자료 구조입니다. 따라서 하드 링크를 만들면, 원본 파일과 링크 파일은 같은 inode를 가리키고, 같은 데이터 블록을 공유합니다. 원본 파일을 삭제해도 하드 링크는 여전히 유효하며, 데이터에 접근할 수 있습니다.

반면, 심볼릭 링크(또는 소프트 링크)는 '바로 가기'와 같습니다. 별도의 inode를 가지고, 원본 파일의 경로를 저장합니다. 원본 파일이 삭제되면 심볼릭 링크는 깨지게 됩니다.

사용 시나리오를 예로 들자면, 중요한 설정 파일의 백업을 위해 하드 링크를 사용할 수 있습니다. 원본 파일이 실수로 삭제되더라도 하드 링크를 통해 데이터를 복구할 수 있습니다. 심볼릭 링크는 자주 사용하는 파일이나 디렉토리에 빠르게 접근하기 위해 사용합니다. 예를 들어, 긴 경로의 설정 파일을 홈 디렉토리에 심볼릭 링크로 만들어 편리하게 접근할 수 있습니다.

ss 명령어가 netstat에 비해 가지는 주요 장점은 성능과 기능입니다. netstat은 /proc 파일 시스템을 통해 정보를 가져오기 때문에 오버헤드가 큰 반면, ss는 Netlink Socket을 사용하여 커널 공간에서 직접 정보를 가져와 훨씬 빠르고 효율적입니다. 또한, ss는 IPv6, SCTP와 같은 최신 프로토콜을 더 잘 지원하며, 더 다양한 필터링 옵션을 제공합니다.

특정 포트의 ESTABLISHED 연결만 필터링하려면 다음과 같이 ss 명령어를 사용할 수 있습니다. 예를 들어 8080 포트의 연결을 확인하려면 다음과 같이 합니다.

ss -t state established '( dport = :8080 )'

-t 옵션은 TCP 연결을, state established는 ESTABLISHED 상태의 연결을 필터링합니다. '( dport = :8080 )'는 목적지 포트가 8080인 연결만 보여주도록 필터링하는 역할을 합니다.

LVM(Logical Volume Manager)은 물리적인 저장 공간을 추상화하여 논리적인 볼륨으로 관리하는 방식입니다. 일반적인 파티셔닝 방식은 파티션 크기를 미리 고정해야 하지만, LVM은 필요에 따라 논리 볼륨의 크기를 유연하게 조정할 수 있다는 장점이 있습니다. 또한 스냅샷 기능을 통해 특정 시점의 데이터 백업 및 복구가 용이합니다.

LVM을 사용하여 기존 논리 볼륨의 크기를 확장하는 절차는 다음과 같습니다. 먼저, 물리 볼륨(PV)을 생성하고, 이를 볼륨 그룹(VG)에 추가합니다. 그 다음, lvextend 명령어를 사용하여 논리 볼륨(LV)의 크기를 확장합니다. 마지막으로, resize2fs (ext4 파일 시스템의 경우) 또는 xfs_growfs (XFS 파일 시스템의 경우) 명령어를 사용하여 파일 시스템의 크기를 확장된 논리 볼륨에 맞게 조정합니다. 이 과정을 통해 시스템 중단 없이 온라인으로 볼륨 확장이 가능합니다.

패키지 관리자는 소프트웨어 설치 시 의존성 문제를 해결하기 위해 패키지 메타데이터를 활용합니다. 이 메타데이터에는 해당 패키지가 정상적으로 작동하기 위해 필요한 다른 패키지 및 라이브러리 정보가 담겨 있습니다.

apt나 yum 같은 패키지 관리자는 먼저 설치하려는 패키지의 메타데이터를 확인하고, 의존성 목록을 파악합니다. 그 후, 설정된 저장소(repository)에서 해당 의존성들을 찾아서 함께 설치합니다. 만약 의존성 패키지에도 또 다른 의존성이 있다면, 이 과정을 재귀적으로 반복하여 모든 의존성을 해결합니다.

특정 패키지의 의존성 목록을 확인하는 방법은 다음과 같습니다. apt를 사용하는 경우 apt-cache depends [패키지 이름] 명령어를, yum을 사용하는 경우 yum deplist [패키지 이름] 명령어를 사용하면 됩니다. 예를 들어, apt-cache depends apache2를 실행하면 apache2 패키지의 의존성 목록을 확인할 수 있습니다.

journalctl은 systemd 시스템에서 로그를 조회하고 분석하는 강력한 도구입니다. 효과적으로 사용하기 위해 몇 가지 방법을 설명드리겠습니다.

특정 서비스의 로그만 확인하려면 -u 옵션을 사용합니다. 예를 들어, nginx 서비스의 로그를 보려면 journalctl -u nginx라고 입력합니다. 이렇게 하면 nginx 서비스와 관련된 모든 로그 메시지가 표시됩니다.

특정 시간 범위의 로그를 필터링하려면 --since와 --until 옵션을 사용합니다. 예를 들어, 2023년 10월 26일 0시부터 2023년 10월 27일 0시까지의 로그를 보려면 journalctl --since "2023-10-26 00:00:00" --until "2023-10-27 00:00:00"라고 입력합니다. 날짜와 시간을 다양한 형식으로 지정할 수 있으며, "yesterday", "today", "1 hour ago"와 같은 상대적인 시간 표현도 사용할 수 있습니다.

로그 레벨에 따라 필터링도 가능합니다. -p 옵션을 사용하여 journalctl -p err와 같이 에러 로그만 확인할 수 있습니다.

이 외에도 다양한 옵션을 조합하여 원하는 로그를 효율적으로 검색하고 분석할 수 있습니다. man journalctl 명령어를 통해 더 자세한 내용을 확인할 수 있습니다.

네, 이해했습니다. 면접에서 답변하는 것처럼 자연스럽고 간결하게 작성해보겠습니다.

cgroups와 namespaces는 컨테이너 기술의 핵심입니다. namespaces는 프로세스, 네트워크, 파일 시스템 등을 격리하여 컨테이너가 마치 독립된 시스템처럼 보이게 합니다. 예를 들어, PID namespace를 사용하면 컨테이너 내부의 프로세스는 PID 1번부터 시작할 수 있습니다.

cgroups는 CPU, 메모리, I/O 등 시스템 리소스 사용량을 제한하고 격리합니다. 컨테이너가 과도하게 리소스를 사용하는 것을 방지하여 다른 컨테이너나 호스트 시스템에 영향을 주지 않도록 합니다.

이 둘은 함께 작동하여 컨테이너 격리를 구현합니다. namespaces로 격리된 환경을 만들고, cgroups로 리소스 사용량을 제한하는 것이죠. Docker나 Kubernetes 같은 컨테이너 런타임은 이 두 가지 커널 기능을 활용하여 컨테이너를 실행하고 관리합니다.

대규모 I/O 부하 환경에서는 XFS를 선택하겠습니다.

XFS는 대용량 파일 및 디렉토리 처리에 최적화되어 있으며, Extent 기반 할당 방식을 사용하여 파일 조각화를 줄이고 연속적인 I/O 성능을 높입니다. 또한, XFS는 메타데이터 저널링 방식을 사용하여 데이터 무결성을 보장하면서도 ext4의 데이터 저널링 방식보다 오버헤드가 적어 높은 I/O 처리량을 유지할 수 있습니다.

ext4는 작은 파일 처리에 강점이 있고 안정성이 높지만, 대규모 I/O 환경에서는 XFS의 Extent 기반 할당과 효율적인 저널링 방식이 더 유리합니다. ext4는 B-Tree 구조를 사용하며, 저널링 시 데이터와 메타데이터 모두를 기록하는 방식(데이터 저널링)을 선택할 수 있어 복구 시 안전하지만, I/O 성능 저하의 원인이 될 수 있습니다.

네, 고성능 웹 서버 환경에서 네트워크 지연 시간을 줄이고 처리량을 극대화하기 위해 TCP/IP 스택 튜닝은 매우 중요합니다. 몇 가지 핵심 커널 파라미터를 예시로 들어 설명드리겠습니다.

첫째, net.ipv4.tcp_tw_reuse는 TIME_WAIT 상태의 소켓을 재사용하도록 설정하여, 빠르게 연결을 맺고 끊는 웹 서버 환경에서 유용합니다. 이 값을 1로 설정하면 TIME_WAIT 상태의 소켓을 새로운 연결에 재사용할 수 있어 자원 고갈을 방지하고 연결 속도를 향상시킬 수 있습니다.

둘째, net.core.somaxconn은 LISTEN 상태의 소켓에 대해 대기할 수 있는 최대 연결 요청 수를 설정합니다. 기본값이 낮으면 갑작스러운 트래픽 증가 시 연결 요청이 손실될 수 있으므로, 웹 서버의 예상 트래픽에 맞춰 적절히 늘려주는 것이 좋습니다. 예를 들어 sysctl -w net.core.somaxconn=65535 와 같이 설정할 수 있습니다.

셋째, net.ipv4.tcp_max_syn_backlog는 SYN flood 공격을 방어하고, 동시에 처리할 수 있는 SYN 요청 수를 늘려줍니다. 이 값을 늘리면 SYN flood 공격에 대한 내성을 강화하고, 정상적인 연결 요청 처리 능력을 향상시킬 수 있습니다.

이 외에도 TCP Keepalive 설정, Congestion Control Algorithm 선택, net.ipv4.tcp_window_scaling 활성화 등 다양한 방법으로 네트워크 성능을 최적화할 수 있습니다.

시스템 호출 성능 병목 현상을 진단하고 최적화하는 데는 eBPF, perf, ftrace 같은 고급 도구를 활용합니다.

eBPF는 커널에 안전하게 사용자 정의 코드를 삽입하여 시스템 호출의 실행 시간, 인자 값 등을 실시간으로 추적할 수 있게 해줍니다. 예를 들어, 특정 시스템 호출의 빈도가 높거나 실행 시간이 길다면 eBPF 프로그램을 통해 해당 호출을 발생시키는 프로세스를 식별하고, 원인을 분석할 수 있습니다.

perf는 CPU 성능 카운터를 활용하여 시스템 전체의 성능 프로파일링을 수행합니다. 이를 통해 시스템 호출과 관련된 CPU 사용률, 캐시 미스 등을 파악하여 병목 지점을 찾을 수 있습니다.

ftrace는 커널 함수 호출을 추적하는 데 사용됩니다. 시스템 호출의 내부 동작을 자세히 분석하여 어떤 함수가 가장 많은 시간을 소모하는지, 어떤 경로로 실행되는지 등을 파악할 수 있습니다.

실제 시나리오에서는 웹 서버의 응답 시간이 느려지는 경우, eBPF를 사용하여 read 또는 write 시스템 호출의 오버헤드를 분석하고, perf를 통해 CPU 사용률을 확인하며, ftrace를 통해 네트워크 스택의 함수 호출 흐름을 추적하여 병목 지점을 찾아 해결할 수 있습니다. 컨텍스트 스위칭이 잦다면, 스케줄러 관련 정보를 eBPF로 추적하여 개선할 부분을 찾을 수 있습니다.

네, 말씀하신 내용에 대해 설명드리겠습니다.

Linux 커널에서 메모리가 부족해지면 OOM (Out Of Memory) Killer가 동작합니다. OOM Killer는 시스템의 안정성을 위해 메모리를 가장 많이 사용하거나, 중요도가 낮은 프로세스를 강제로 종료하여 메모리를 확보합니다.

OOM Score는 각 프로세스에 할당되는 점수로, OOM Killer가 어떤 프로세스를 먼저 종료할지 결정하는 기준이 됩니다. 점수가 높을수록 종료될 가능성이 높습니다. OOM Score는 프로세스의 메모리 사용량, 실행 시간, 권한 등을 고려하여 계산됩니다.

스와핑은 RAM의 내용을 디스크로 옮겨 RAM 공간을 확보하는 메커니즘입니다. 메모리가 부족할 때 유용하지만, 디스크 I/O는 RAM 접근보다 훨씬 느리기 때문에 시스템 성능 저하를 유발합니다.

스와핑 성능 최적화는 swappiness 값을 조절하는 방식으로 이루어집니다. swappiness는 커널이 RAM의 내용을 얼마나 적극적으로 스왑 공간으로 옮길지 결정하는 파라미터입니다. 값이 낮을수록 스와핑을 덜 사용하고, 높을수록 더 적극적으로 사용합니다. 일반적으로 서버 환경에서는 swappiness 값을 낮춰 스와핑을 최소화하고, 메모리 부족 상황을 최대한 늦추는 것이 좋습니다. 예를 들어, sysctl vm.swappiness=10과 같이 설정할 수 있습니다.

SELinux나 AppArmor 같은 MAC(Mandatory Access Control) 시스템은 기존 DAC(Discretionary Access Control) 방식과 접근 제어 방식에서 근본적인 차이가 있습니다. DAC는 사용자나 그룹에게 권한을 부여하여 접근을 제어하는 반면, MAC은 시스템 관리자가 정의한 정책에 따라 프로세스의 리소스 접근을 강제합니다. 즉, DAC는 사용자의 재량에 따라 권한이 변경될 수 있지만, MAC은 정책에 의해 엄격하게 통제됩니다.

실제 운영 환경에서 MAC을 효과적으로 적용하려면, 먼저 시스템의 역할과 필요한 보안 수준을 명확히 정의해야 합니다. 그 후, 각 역할에 맞는 정책을 설계하고 적용해야 합니다. 정책 관리는 semanage (SELinux)나 aa-status (AppArmor) 같은 도구를 사용하여 수행할 수 있습니다. 트러블슈팅 시에는 auditd 로그를 분석하여 접근 거부 상황을 파악하고, 정책을 수정하거나 예외 규칙을 추가하여 문제를 해결할 수 있습니다. 예를 들어, 특정 프로세스가 필요한 파일에 접근하지 못하는 경우, audit 로그를 확인하고 해당 프로세스에 필요한 권한을 부여하는 정책을 추가합니다.

systemd에서 .target 파일은 여러 .service 파일들을 묶어 특정 시스템 상태를 정의하는 역할을 합니다. 예를 들어 multi-user.target은 다중 사용자 환경을 구성하는 데 필요한 서비스들을 묶어 놓은 것이죠. .service 파일은 개별 서비스의 실행 방식, 즉 시작/종료/재시작 방법 등을 정의합니다.

이 둘의 관계를 통해 서비스 의존성을 관리하고 부팅 프로세스를 최적화할 수 있습니다. Requires, Wants, After 등의 옵션을 사용해서 서비스 간의 의존 관계를 명확하게 설정하는 것이 중요합니다. Requires는 필수 의존성, Wants는 권장 의존성, After는 실행 순서를 지정합니다.

사용자 정의 서비스 유닛을 작성할 때는 ExecStart, Type, User 등의 옵션을 신중하게 고려해야 합니다. 예를 들어, 데몬 프로세스를 실행하는 서비스라면 Type=forking 또는 Type=simple을 적절히 선택하고, 보안을 위해 User 옵션을 통해 특정 사용자로 실행되도록 설정할 수 있습니다. 또한, 서비스가 실패했을 때 자동으로 재시작되도록 Restart 옵션을 설정하는 것도 좋은 방법입니다.