| /etc/shell 파일 생성 | LFS 시스템 부팅 설정 |
etc/systemd/system.conf 파일에는 기본 systemd 작업을 제어하는 옵션이 포함되어 있습니다. 기본 파일에는 모든 항목이 주석 처리되어 있으며 기본 설정이 표시되어 있습니다. 이 파일에서 로그 수준과 몇 가지 기본 로깅 설정을 변경할 수 있습니다. 각 구성 옵션에 대한 자세한 내용은 systemd-system.conf(5) 매뉴얼 페이지를 참조하세요.
systemd의 정상적인 동작은 부팅 시퀀스가 끝날 때 화면을 지우는 것입니다. 원하는 경우 다음 명령을 실행하여 이 동작을 변경할 수 있습니다.
mkdir -pv /etc/systemd/system/getty@tty1.service.d
cat > /etc/systemd/system/getty@tty1.service.d/noclear.conf << EOF
[Service]
TTYVTDisallocate=no
EOF
journalctl -b 명령을 사용하여 언제나 검토할 수 있습니다.
기본적으로 /tmp는 tmpfs로 생성됩니다. 이를 원하지 않는 경우 다음 명령을 실행하여 재정의할 수 있습니다.
ln -sfv /dev/null /etc/systemd/system/tmp.mount
/tmp를 위한 별도의 파티션이 필요한 경우 /etc/fstab 항목에 해당 파티션을 지정합니다.
경고
별도의 파티션을 /tmp에 사용하는 경우 위에 나오는 심볼릭 링크를 만들지 마세요. 이렇게 하면 루트 파일 시스템(/)을 다시 마운트할 수 없게 되어 부팅 시 시스템을 사용할 수 없게 됩니다.
파일 또는 디렉터리를 만들거나 삭제하는 몇 가지 서비스가 있습니다.
구성 파일의 시스템 위치는 /usr/lib/tmpfiles.d/*.conf입니다. 로컬 구성 파일은 /etc/tmpfiles.d에 있습니다. /etc/tmpfiles.d의 파일은 /usr/lib/tmpfiles.d의 같은 이름을 가진 파일을 재정의합니다. 파일 형식에 대한 자세한 내용은 tmpfiles.d(5) 매뉴얼 페이지를 참조하세요.
usr/lib/tmpfiles.d/*.conf 파일의 구문이 혼동될 수 있다는 점에 유의하세요. 예를 들어 /tmp 디렉터리에 있는 파일의 기본적인 삭제 정의는 /usr/lib/tmpfiles.d/tmp.conf에 다음과 같은 줄이 있습니다.
q /tmp 1777 root root 10d
기본 매개 변수를 원하지 않는 경우에는 파일을 /etc/tmpfiles.d에 복사하고 원하는 대로 편집해야 합니다. 예를 들어
mkdir -p /etc/tmpfiles.d
cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d
etc/systemd/system 디렉토리를 생성하고 구성 파일을 작성하여 유닛의 매개변수를 재정의할 수 있습니다. 예를 들면 다음과 같습니다
mkdir -pv /etc/systemd/system/foobar.service.d
cat > /etc/systemd/system/foobar.service.d/foobar.conf << EOF
[Service]
Restart=always
RestartSec=30
EOF
SysVinit 또는 BSD 스타일의 init 시스템에서 사용되는 일반 셸 스크립트 대신 systemd는 다양한 유형의 시작 파일(또는 단위)에 대해 일관된 형식을 사용합니다. systemctl 명령은 단위 파일의 활성화, 비활성화, 상태 제어 및 상태 확인에 사용됩니다. 다음은 자주 사용되는 명령의 몇 가지 예입니다.
systemd로 부팅된 시스템의 로그온은 일반적인 유닉스 syslog daemon이 아닌 systemd-journald(기본값)로 처리됩니다. 원하는 경우 일반 syslog daemon을 추가하여 둘을 나란히 작동하도록 할 수도 있습니다. systemd-journald 프로그램은 저널 항목을 일반 텍스트 로그 파일이 아닌 바이너리 형식으로 저장합니다. 파일 구문 분석을 돕기 위해 journalctl 명령이 제공됩니다. 다음은 자주 사용되는 명령의 몇 가지 예입니다.
코어 덤프는 특히 데몬 프로세스가 충돌할 때 충돌한 프로그램을 디버깅하는 데 유용합니다. 시스템드 부팅 시스템에서 코어 덤프는 systemd-coredump에 의해 처리됩니다. 이 함수는 코어 덤프를 저널에 기록하고 코어 덤프 자체를 /var/lib/systemd/coredump에 저장합니다. 코어 덤프를 검색하고 처리하기 위해 coredumpctl 도구가 제공됩니다. 다음은 자주 사용되는 명령어의 몇 가지 예입니다.
코어 덤프는 디스크 공간을 많이 사용할 수 있습니다. 코어 덤프가 사용하는 최대 디스크 공간은 다음과 같이 /etc/systemd/coredump.conf.d에 구성 파일을 생성하여 제한할 수 있습니다.
mkdir -pv /etc/systemd/coredump.conf.d
cat > /etc/systemd/coredump.conf.d/maxuse.conf << EOF
[Coredump]
MaxUse=5G
EOF
systemd-230부터는 사용자 세션이 종료되면 nohup이 사용되거나 프로세스가 daemon() 또는 setsid() 함수를 사용하는 경우에도 모든 사용자 프로세스가 종료됩니다. 이는 과거에 허용되던 환경에서 보다 제한적인 환경으로 의도적으로 변경된 것입니다. 새로운 동작은 사용자 세션을 종료한 후에도 활성 상태를 유지하기 위해 오래 실행되는 프로그램(예: 화면 또는 tmux)에 의존하는 경우 문제를 일으킬 수 있습니다. 사용자 세션이 종료된 후에도 프로세스가 남아 있도록 하는 세 가지 방법이 있습니다.
user 인수와 함께 사용하여 사용자에 대해 활성화할 수 있습니다. 그러면 해당 사용자는 systemd-run 명령을 사용하여 오래 실행 중인 프로세스를 시작할 수 있습니다. 예를 들어 systemd-run –scope –user /usr/bin/screen 이런 형식입니다.. 사용자에 대해 지속을 사용하도록 설정하면 모든 로그인 세션이 종료된 후에도 user@.service가 유지되며 시스템 부팅 시 자동으로 시작됩니다. 이 방법은 사용자 세션이 종료된 후 프로세스의 실행을 명시적으로 허용하거나 허용하지 않을 수 있다는 장점이 있지만 nohup과 같은 도구 및 daemon()을 사용하는 유틸리티와의 하위 호환성이 깨집니다.etc/systemd/logind.conf에서 KillUserProcesses=no를 설정하여 모든 사용자에 대해 전역적으로 프로세스 지속을 활성화할 수 있습니다. 이 방법은 명시적인 제어를 희생하는 대신 모든 사용자가 기존 방법을 사용할 수 있다는 이점이 있습니다.