Skip to content

Systemd

systemd is a suite of basic building blocks for a Linux system.

Categories

Unit configuration 

[Unit]
Requires= # 다른 unit들과 dependency를 정의하는 부분.
          # 다른 unit이 activation이 실패하면 같이 실패 됨.

Wants=    # Requires와 같은 기능을 하지만 다른 unit이 activation 실패해도 
          # 영향을 받지 않음. 따라서 다른 unit이 start-up할 때 hooking 하여
          # 같이 실행 될 때 사용함.

Before=   # dependency 있는 unit들을 ordering하는 속성.
After=    # 만약 foo.service unit에 Before=bar.service를 설정하면
          # foo.service가 다 strat-up 될 때 까지 bar.service unit은 delay 됨.
          # 죽, 내 before=로 설정한 unit 전에 실행 시키라는 속성.


[Install] # systemd의 runtime에 interpret되는 것이 아니라 unit을 설치하는 
          # systemd enable/disable command에 의해 영향을 받는 section

WantedBy=   # 이 option을 설정하면 systemlctl enable시 .wants/ .requires/
RequiredBy= # 폴더에 symbolic link를 생성해줌.


[Service]  # 서비스 실행에 대한 내용

# 여러 줄로 명령을 주고 싶다면 "\"을 준다:
ExecStart=java -server -Xms124M -Xmx1024M -XX:+HeapDumpOnOutOfMemoryError \
    -classpath /usr/local/plcGateway/lib/* \
    com.mseo.main.main /usr/local/plcGateway/cfg

Restart=on-failure  # 재시작 조건
RestartSec=5  # 재 시작 시 대기 시간. (너무 빨리 재시작 시키는걸 방지)

Wants vs After

Wants=
"해당 유닛을 같이 시작해라"는 의미입니다. 만약 network-online.target이 아직 활성화 안 되어 있으면 systemd가 알아서 시작시켜 줍니다. 단, 그 유닛이 실패해도 내 서비스는 그냥 시작됩니다.
After=
는 "해당 유닛이 끝난 다음에 내 서비스를 시작해라"는 순서 지정입니다. 시작을 요청하지는 않고, 만약 둘 다 시작 대상이라면 순서만 보장합니다.

핵심 차이를 정리하면:

상황

Wants

After

역할

의존 유닛 시작 요청

시작 순서 보장

상대가 없으면

시작시킴

아무 효과 없음

상대가 실패하면

내 서비스는 그냥 시작

내 서비스는 그냥 시작

만약 Wants= 와 After= 둘이 함께 있으면 "상대 유닛을 시작시키되, 그게 완료된 후에 내 서비스를 시작해라" 가 됩니다.

그래서 보통 둘을 같이 씁니다. Wants=만 쓰면 동시에 병렬 시작될 수 있고, After=만 쓰면 상대 유닛이 시작 대상에 포함되지 않을 수 있기 때문입니다.

참고로 Requires=는 Wants=의 강한 버전으로, 상대 유닛이 실패하면 내 서비스도 함께 중단됩니다. Nebula처럼 네트워크 없으면 어차피 죽는 서비스에는 Requires=를 써도 괜찮지만, Wants=가 좀 더 유연합니다.

Network Targets

Network Configuration Synchronization Points

  • network.target - 네트워크 서비스가 Active 상태인지 확인한다.
  • network-online.target - 네트워크 인터페이스가 UP 상태인지 확인한다.
  • systemd-resolved.service - DNS 해석에 관련된 서비스

그래서 보통 네트워크가 연결되었을 경우를 가정한 셋팅은 다음과 같다: 

[Unit]
After=network-online.target systemd-resolved.service
Wants=network-online.target systemd-resolved.service

만약 하나만 쓰면:

  • Wants=만 → 시작은 시키지만 기다리지 않음 (병렬 실행되어 같은 문제 재발 가능)
  • After=만 → 순서는 보장하지만, network-online.target이 시작 대상에 없으면 아무 의미 없음

그래서 "네트워크가 준비된 다음에 시작해야 하지만 만약 없거나 실패해도 시작해라" 를 보장하는 서비스에는 항상 둘을 세트로 쓰는 게 관례입니다.

정확히 표현하면 "기다리되, 결과에 상관없이 시작한다"가 맞습니다. 사실상 best-effort 의존성이라고 볼 수 있어요.

multi-user.target

run-level-3이 시작됨을 알려준다.

서비스 파일 등록

systemd는 기본적으로 루트 권한으로 실행된다. 해당 디렉토리는/etc/systemd/system/ 이다. 이 곳에 서비스이름.service 파일을 추가하고 다음 명령으로 활성화 할 수 있다. 

systemctl daemon-reload
systemctl enable 서비스이름
systemctl start 서비스이름

--user 옵션을 사용하는 일반 사용자 서비는 $HOME/.config/systemd/user 이다. 

systemctl --user daemon-reload
systemctl --user enable 서비스이름
systemctl --user start 서비스이름

노트북 화면 꺼짐 조정

노트북 화면 덮개(LID)를 닫아도 대기(Suspend) 상태로 빠지지 않도록 하는 방법이다.

Edit /etc/systemd/logind.conf and make sure you have: 

HandleLidSwitch=ignore

그리고 아래 명령을 날린다: 

$ systemctl restart systemd-logind

Power management 항목 및 ArchWiki 참조.

또다른 방법 (?)

You can use this to temporarily disable lid-switch events: 

$ systemd-inhibit --what=handle-lid-switch sleep 1d

키워드

Hibernate, lid, Power management, acpi, 등 으로 검색...

임베디드 리눅스에서 systemd가 문제가 되는 이유

주로 자원을 많이 사용하느 이슈 등

  • systemd는 많은 문제를 해결하며, 커뮤니티도 매우 응답성이 좋고 도움이 됨
    • 가끔 이상한 문제가 있지만 항상 해결책이 존재함
    • 메모리 사용은 중요하지 않으며, 대부분의 임베디드 Linux 장치는 1GB 이상의 RAM을 가짐
    • 작은 장치에서는 Zypher나 FreeRTOS를 사용함
  • OpenEmbedded/Yocto, Devuan, Gentoo는 여러 init 시스템을 제공함
  • Rustysd는 systemd의 동작을 일부 복제하는 서비스 관리자임
    • core 기능을 제공하며, 다양한 플랫폼에 systemd와 유사한 서비스 관리자를 제공할 수 있음
  • systemd를 선호하는 사람들은 주로 배포 관리자임
    • systemd는 다양한 시스템 유틸리티를 하나의 큰 빌드로 제공함
  • Unix 철학은 작은 도구들이 문제를 해결하는 것임
    • systemd는 초기에는 작았으나, 현재는 웹 기반으로 비디오 회의도 가능함
  • runit는 애플리케이션과 서비스를 감독하는 데 훌륭함
    • BusyBox에 내장되어 있으며 매우 가벼움
    • 설정이 매우 간단하며, 로깅 기능도 포함됨
    • Unix 철학을 거의 완벽하게 구현함
  • udev 없이 임베디드 시스템을 실행할 수 있음
    • 고정된 주변 장치와 커널 모듈을 사용하는 경우 가능함
  • RPi는 산업용 제어 보드의 폼 팩터를 데스크탑으로 변환함
    • 많은 소프트웨어가 이 세그먼트를 염두에 두고 작성되지 않음
  • Chimera Linux는 서비스 관리와 로그인/좌석 관리에서 흥미로운 방향으로 나아가고 있음
    • systemd의 gnulibc와 gcc 확장 사용이 문제임
  • systemd의 설치 크기가 임베디드 Linux에서 가장 큰 문제임
    • 64M RAM과 128M NAND 플래시를 가진 장치에서는 5M의 systemd가 비효율적임
  • systemd는 250MB의 RAM을 사용하여 임베디드 Linux에서 문제가 됨
    • mainstream 배포판을 고려하지 않는 시스템에서는 큰 문제가 아님
  • SysVInit는 외부 유틸리티에 의존하여 프로세스를 시작하고 중지함
    • 최소한의 경우에도 init 스크립트를 실행하기 위해 셀이 필요함

SystemD 서비스 보안 강화

systemd는 강력한 서비스 관리 기능을 제공하지만 기본 설정은 보안보다는 사용성에 최적화되어 있어 별도의 하드닝 옵션 적용이 필요함

  • systemd-analyze security 명령어를 통해 전체 서비스 또는 특정 서비스의 보안 노출 지표를 분석하고 우선순위를 정할 수 있음
  • 서비스 단위에서 적용할 수 있는 다양한 보안 옵션이 존재하며, 이는 /etc/systemd/system/ServiceName.service.d/override.conf 등을 통해 개별적으로 수정 가능함
  • 주요 옵션에는 ProtectSystem, PrivateTmp, NoNewPrivileges, SystemCallFilter, MemoryDenyWriteExecute 등 프로세스 권한과 자원 접근을 제한하는 항목이 포함됨
  • 완벽한 보안을 목표로 하기보다는 외부 노출 서비스를 우선적으로 하드닝하여 위험을 줄이고, self-hosting 환경에서도 큰 효과를 볼 수 있음

Example

Docker example 

[Unit]
Description=apache2
After=mysql.service
Requires=mysql.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill apache2-server
ExecStartPre=-/usr/bin/docker rm apache2-server
ExecStart=/usr/bin/docker run -p 60004:80 --volumes-from apache2-volume --volumes-from mysql-volume -v /etc/localtime:/etc/localtime:ro --name apache2-server apache2-server
ExecStop=/usr/bin/docker kill apache2-server

[Install]
WantedBy=multi-user.target

JupyterNotebook service 

$ sudo nano /etc/systemd/system/jupyterNotebook.service

[Unit]
Description=Jupyter Notebook Server

[Service]
Type=simple
User=<username>
ExecStart=/home/<username>/.local/bin/jupyter-notebook
WorkingDirectory=/your/working/dir

[Install]
WantedBy=multi-user.target

$ systemctl daemon-reload
$ systemctl enable jupyterNotebook
$ systemctl start jupyterNotebook

ANSWER 

[Unit]
Description=The ANSWER, No-code development platform

[Service]
Environment=RECC_VERBOSE=2
Environment=RECC_DEVELOPER=true
Environment=PYTHONPATH="/home/yourname/Project/answer/core"
ExecStart="/home/yourname/.pyenv/versions/opy-yourname-3.8.9/bin/python" -m recc core --storage-root "/home/yourname/Project/answer/core/storage"
User=root
Group=root

[Install]
WantedBy=multi-user.target

한번만 실행 

[Unit]
Description=Set DNS for Nebula Interface
After=nebula.service

[Service]
ExecStart=/usr/local/bin/set-nebula-dns.sh
Type=oneshot
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

vs chkconfig

What about chkconfig? That changed too? Yes, now you want to use systemctl for the chkconfig commands also..

systemctl enable httpd
chkconfig service on
systemctl disable httpd
chkconfig service off
systemctl is-enabled httpd
chkconfig service (is it set up to start?)
systemctl list-unit-files --type=service
chkconfig –list (shows what is and isn’t enabled)

LogNamespace

Journalctl#LogNamespace 항목 참조.

Troubleshooting

systemctl restart등을 사용하여 서비스 실행에 실패했을 경우 journalctl -xe를 사용하면 로그를 확인할 수 있다.

See also

Favorite site

References

  1. Systemctl_-_PGWiki.pdf ↩