개념 사전/시스템 · 서버 / 프로세스·서비스
개념 사전 · 프로그램

systemd

시스템디

는 에서 서비스와 여러 시스템 자원을 unit으로 정의하고 실행 생애를 관리하는 프로그램이다. 서비스 시작 완료의 기준·의존 관계·실행 계정·재시작 정책을 설정으로 표현하지만 활성 상태가 업무 응답 성공을 항상 뜻하지는 않는다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

  • 서비스 실행 계정·환경· 집합을 관리한다.
  • unit의 요구 관계와 순서 관계에 따라 시작·중지를 조정한다.
  • 종료 원인·재시작·시작 빈도 제한과 로그를 연결한다.

02어떤 순서로 동작하나

  1. unit 읽기

    관리자가 시작을 요청하면 로드한 unit과 의존 관계에 따라 필요한 시작 작업을 준비한다.

  2. 실행 준비

    User·Group·WorkingDirectory·ExecStart 등의 조건을 적용해 를 시작한다.

  3. 시작 완료 판정

    Type=simple··notify·oneshot 등 지정한 형식에 맞춰 시작 완료와 활성 상태를 판단한다.

  4. 종료와 재시작

    종료 이유를 Restart 정책과 비교하고 RestartSec·시작 제한 등 조건에 따라 다시 시작하거나 실패 상태를 남긴다.

03먼저 알아둘 용어와 구성요소

[Unit]은 설명과 의존 관계를, [Service]는 실행 방법과 속성을, [Install]은 enable할 때 만들 연결을 선언한다.
는 애플리케이션이 준비 완료 알림을 보내도록 협력하는 방식이다.
=db.service는 함께 시작할 대상을 끌어오지만 그 시작 실패가 항상 요청한 서비스를 실패시키지는 않는다. 기능을 선택적으로 결합할 때 쓰는 약한 요구 관계다.
와 를 함께 두면 선행 unit의 시작 실패 때문에 후행 unit의 시작이 진행되지 않을 수 있다. 만으로 선행 시작 완료를 기다리는 순서가 생기지는 않는다.
=db.service는 두 작업이 모두 예정됐을 때 시작 순서를 정한다. db.service를 시작 작업에 포함시키는 효과는 · 등 별도 관계에서 온다.
unit 파일을 수정한 뒤 를 수행하면 가 unit 정의와 의존 관계를 다시 읽는다.
LEARN THROUGH PRACTICE

SSH 서비스의 active와 enabled를 서로 다른 상태로 읽기

서비스를 지금 시작하는 작업과 부팅 시 시작 경로를 등록하는 작업을 실제 status 출력으로 구별한다.

실습 구성과 전제

  • 의 ssh.service 화면을 사용한다. 배포판에 따라 같은 서버 프로그램의 unit 이름이 sshd.service일 수 있다.
  • 첫 화면과 enable 이후 화면은 Main PID와 시작 시각을 대조해 읽는다. socket activation 표시도 함께 살핀다.

  1. 현재 실행 상태를 읽는다

    • start는 현재 서비스의 시작을 요청한다. status의 Active가 active (running)이면 해당 unit의 실행 상태를 뜻하며, 부팅 때 자동 시작하도록 등록되었다는 뜻은 아니다.
    • ExecStartPre의 sshd 검사 성공과 Main PID를 보면 사전 검사와 실제 서버 를 분리할 수 있다. TriggeredBy의 ssh.socket은 별도 소켓 unit과의 관계다.
    bash
    systemctl status ssh.service --no-pager
systemctl is-active ssh.service
systemctl is-enabled ssh.service

    예시다. 각 조회 명령의 출력과 종료 상태는 서로 다른 질문에 답한다.

    4/22 · 명령·상태 출력 2원본 크기로 보기 ↗
    • Loaded 줄에는 disabled가 보이지만 Active 줄은 active (running)이다.
    • ExecStartPre의 종료 상태는 성공이고 Main PID가 표시되며, ssh.socket의 트리거 관계도 나타난다.
    확인 기준

    active와 disabled는 모순이 아니다. 실행 여부와 unit 파일의 활성화 상태를 별도 열로 기록한다.

  2. enable이 만든 시작 경로를 확인한다

    • enable은 unit의 설치 지시를 바탕으로 target의 같은 연결을 만든다. 기본 enable만으로 현재 를 새로 실행하거나 재시작하지 않는다.
    • 화면에서는 enable 후 생성 메시지가 나오고 Loaded가 enabled로 바뀐다. 이미 실행 중인 서버의 Main PID가 이어지는 것이 이 차이를 보여 준다.
    4/22 · 명령·상태 출력 3원본 크기로 보기 ↗
    • enable 출력에 multi-user.target.wants/ssh.service 등의 연결 생성 메시지가 보인다.
    • Loaded는 enabled로 바뀌었고 Active는 여전히 running이며 기존 Main PID가 유지된다.
    확인 기준

    enable --now는 활성화 등록과 현재 시작을 함께 요청하는 옵션이다. enable만 실행한 사례와 구분한다.

  3. 서비스·소켓·부팅 경로를 함께 대조한다

    • is-enabled만으로 서버가 현재 수신 가능한지 판단하지 않는다. 서비스 실패, 소켓 unit의 활성화, 실제 리슨 포트를 각각 확인한다.
    • 소켓 활성화를 사용하는 배포판에서는 ssh.socket이 연결을 받아 서비스를 시작할 수 있다. unit 파일과 현재 소켓 상태를 확인한 뒤 해당 환경의 시작 경로를 설명한다.
    bash
    systemctl status ssh.socket --no-pager
systemctl cat ssh.service ssh.socket
ss -lnt

    설치된 unit 구성과 리슨 소켓을 읽기 전용으로 대조한다.

    확인 기준

    서비스가 active인데 접속되지 않으면 포트·주소·방화벽을 확인한다. 서비스가 inactive여도 소켓 활성화가 설정되었는지 먼저 살핀다.

실습에서 확인한 동작 원리

  • active는 현재 실행 상태이고 enabled는 시작 의존 관계를 등록한 상태다.
  • 설정 파일, unit 활성화, , 리슨 소켓은 서로 연결되지만 같은 증거는 아니다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

sshd 실행·22번 포트 수신·SSH 인증을 순서대로 확인하기

서비스 상태와 소켓 출력에서 서버 준비를 읽고, 실제 SSH 접속의 실패 단계를 구별한다.

실습 구성과 전제

  • sshd status와 ss 출력은 서로 다른 시점의 화면이다. PID 906과 843이 다르므로 같은 의 동시 조회라고 꾸미지 않는다.
  • 준비한 실습 서버와 사전에 확인한 호스트 키를 사용한다. 주소와 계정은 문서용 값으로 바꾸었다.

  1. 실행 상태와 unit 이름을 확인한다

    • 사례는 sshd.service를 사용한다. status의 running과 Main PID로 현재 데몬 실행을 확인하고 enabled로 시작 설정을 읽는다.
    • 이름이 ssh.service인 배포판도 있으므로 unit 이름을 그대로 복사해 설치 실패로 단정하지 않는다. 가 살아 있다는 사실은 포트나 인증 설정이 맞다는 뜻까지 포함하지 않는다.
    bash
    systemctl status sshd.service --no-pager
journalctl -u sshd.service -n 30 --no-pager

    sshd.service를 사용하는 배포판의 조회 예시다.

    Rocky Linux SSH 준비 · b. ssh 작동 확인 (2)원본 크기로 보기 ↗
    • sshd 서비스가 active (running)이며 enabled로 표시된다.
    • Main PID는 906으로 나타나 서버 프로세스 식별을 제공한다.
    확인 기준

    서비스 실패라면 네트워크 시험 전에 해당 unit의 설정 검사·시작 로그부터 확인한다.

  2. 소켓이 어느 주소·포트에서 수신하는지 읽는다

    • 별도 ss 화면은 22번 포트가 ·에서 LISTEN인 상태를 보여 준다. 같은 출력에 있는 chronyd의 323 소켓은 SSH의 포트가 아니다.
    • 주소가 loopback에만 묶인 경우와 모든 로컬 주소에 수신하는 경우는 외부 도달 조건이 다르다. LISTEN 이후에도 경로와 방화벽을 통과해야 한다.
    bash
    ss -lntp "sport = :22"

    SSH 기본 포트의 리슨을 좁혀 조회한다. 정보에는 추가 권한이 필요할 수 있다.

    Rocky Linux SSH 준비 · d. 22/tcp 포트 확인 (3)원본 크기로 보기 ↗
    • ss 출력에 22번 TCP LISTEN 행과 sshd 프로세스가 표시된다.
    • chronyd의 323 포트 행은 별도 UDP 소켓으로 함께 나열되어 있어 프로토콜을 구분해야 한다.
    확인 기준

    프로토콜·주소·포트·를 한 행 단위로 읽는다. 다른 시점의 PID 차이를 즉시 비정상으로 해석하지 않는다.

  3. 호스트 확인 뒤 사용자 인증과 명령 실행을 구별한다

    • SSH 클라이언트는 연결 뒤 키 교환과 서버 호스트 키 확인을 수행하고 그다음 을 한다. 인증 후 원격 명령 채널을 열어 실행 결과를 받는다.
    • 재구성 명령에서 host key verification failed, permission denied, 원격 명령의 비영 종료는 서로 다른 실패 단계다. 처음 보는 호스트 키를 검증 없이 신뢰하도록 설정하지 않는다.
    bash
    ssh -v -o StrictHostKeyChecking=yes labuser@192.0.2.30 "id"

    신뢰 호스트 키가 미리 등록된 실습 서버에 현재 자격 정보를 조회하는 예시다.

    확인 기준

    서비스·리스너 조회만으로 로그인 성공을 주장하지 않는다. 사전에 등록한 신뢰 호스트에 한해 실제 클라이언트 로그와 명령 종료 상태를 확인한다.

실습에서 확인한 동작 원리

  • 실행과 소켓 수신은 서버 준비를 보여 주며, 실제 암호화·신원 확인·은 클라이언트 연결에서 확인한다.
  • 실패 메시지를 처리 단계에 맞추면 방화벽·호스트 키·사용자 권한 문제를 분리할 수 있다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • =database.service는 둘 다 시작되는 경우의 순서를 정하지만 그것만으로 database.service를 시작하게 만들지는 않는다.
  • Restart=on-failure, RestartSec=3s인 서비스가 비정상 종료하면 정책이 허용하는 조건에서 지연 후 재시도한다. 관리자 stop은 같은 자동 복구 상황이 아니다.
  • unit 파일 수정은 로 관리자가 다시 읽게 하고 실제 프로그램의 새 설정 적용은 reload 지원 여부나 restart 필요성을 따로 결정한다.

05혼동하기 쉬운 점과 확인 기준

  • systemctl cat은 unit 구성, 앱의 설정 검사는 프로그램 고유 설정을 다룬다. 가 앱 내부 설정을 검사하거나 새 실행 파일을 자동으로 기동하는 것은 아니다.
  • active/running인데 소켓이 없다면 초기화·바인딩·작업자 상태를 본다. Type의 시작 성공 기준이 사용자 요청을 처리할 준비 기준과 얼마나 일치하는지 확인한다.
  • 짧은 시간에 실패가 반복되면 StartLimitIntervalSec·StartLimitBurst의 제한으로 다음 시도가 차단될 수 있다. RestartSec만 늘리거나 줄여 설명할 수 없는 상태다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

프로세스·서비스와 systemd실행 중인 프로세스, 서비스 관리 상태, 실제 서비스 응답은 별도로 확인해야 합니다.상세 노트 읽기 →예약 실행과 시간: cron·systemd timer·NTP·chrony예약 시각과 실행 환경, 작업의 성공·중복·누락을 구분하고, 시간 동기화가 로그와 예약 작업에 미치는 영향을 설명한다.상세 노트 읽기 →

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.