시스템화된 대화형 스크립트 및 타이머

소개

Linux용으로 개발할 때 시스템을 켜거나 종료할 때 실행되는 대화형 스크립트를 만드는 작업이 발생합니다. 시스템 V에서는 이것이 쉬웠지만 systemd를 사용하면 조정이 가능합니다. 그러나 자체 타이머를 가질 수 있습니다.

왜 목표가 필요한가요?

대상은 시스템 V -init에서 실행 수준과 유사한 역할을 한다고 종종 기록됩니다. 나는 근본적으로 동의하지 않습니다. 더 많은 서비스가 있으며 패키지를 그룹으로 나눌 수 있으며, 예를 들어 하나의 명령으로 서비스 그룹을 시작하고 추가 작업을 수행할 수 있습니다. 게다가 계층 구조도 없고 종속성만 있습니다.

대화형 스크립트를 실행하여 활성화된 대상의 예(기능 개요)

대상 자체에 대한 설명:

cat installer.target
[Unit]
Description=My installer
Requires=multi-user.target 
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target 
AllowIsolate=yes
Wants=installer.service

이 대상은 multi-user.target이 시작되고 installer.service를 호출할 때 시작됩니다. 그러나 그러한 서비스가 여러 개 있을 수 있습니다.

cat installer.service
[Unit]
# описание
Description=installer interactive dialog

[Service]
# Запустить один раз, когда остальное будет запущенно
Type=idle
# Команда запуска - вызов скрипта
ExecStart=/usr/bin/installer.sh
# Интерактивное взаимодействие с пользователем через tty3
StandardInput=tty
TTYPath=/dev/tty3
TTYReset=yes
TTYVHangup=yes

[Install]
WantedBy=installer.target

마지막으로 실행되는 스크립트의 예는 다음과 같습니다.

#!/bin/bash
# Переходим в tty3
chvt 3
echo "Install, y/n ?"
read user_answer

가장 중요한 것은 시스템이 시작 시 도착해야 하는 대상인 final.target을 선택하는 것입니다. 시작 프로세스 중에 systemd는 종속성을 검토하고 필요한 모든 것을 시작합니다.
final.target을 선택하는 방법에는 여러 가지가 있습니다. 저는 이를 위해 로더 옵션을 사용했습니다.

최종 출시는 다음과 같습니다.

1. 부트로더가 시작됩니다
2. 부트로더는 final.target 매개변수를 전달하여 펌웨어 실행을 시작합니다.
3. Systemd가 시스템을 시작하기 시작합니다. 해당 종속 항목(예: multi-user.target)을 통해 basic.target에서 installer.target 또는 work.target으로 순차적으로 이동합니다. 후자는 시스템을 원하는 모드로 작동시킵니다.

출시를 위한 펌웨어 준비

펌웨어를 생성할 때 시작 시 시스템 상태를 복원하고 종료 시 저장하는 작업이 항상 발생합니다. 상태는 구성 파일, 데이터베이스 덤프, 인터페이스 설정 등을 의미합니다.

Systemd는 동일한 대상에서 프로세스를 병렬로 실행합니다. 스크립트의 시작 순서를 결정할 수 있는 종속성이 있습니다.

내 프로젝트에서 어떻게 작동하나요( https://habr.com/ru/post/477008/ https://github.com/skif-web/monitor)

1. 시스템이 시작됩니다
2. settings_restore.service 서비스가 시작되어 데이터 섹션에 settings.txt 파일이 있는지 확인합니다. 없으면 참조 파일이 해당 위치에 배치되고 시스템 설정이 복원됩니다.
   • 관리자 비밀번호
   • 호스트 이름,
   • 시간대
   • 장소
   • 모든 미디어가 사용되고 있는지 여부를 결정합니다. 기본적으로 이미지 크기는 작아서 미디어에 쉽게 복사하고 기록할 수 있습니다. 시작 시 아직 사용되지 않은 공간이 있는지 확인합니다. 있는 경우 디스크가 다시 파티션됩니다.
   • MAC 주소에서 머신 ID를 생성하는 중입니다. 이는 DHCP를 통해 동일한 주소를 얻는 데 중요합니다.
   • 네트워크 설정
   • 로그 크기 제한
   • 외부 드라이브가 작업 준비 중입니다(해당 옵션이 활성화되어 있고 드라이브가 새 드라이브인 경우).
3. 포스트그레스 시작
4. 복원 서비스가 시작됩니다. zabbix 자체와 데이터베이스를 준비하는 데 필요합니다.
   • 이미 zabbix 데이터베이스가 있는지 확인합니다. 그렇지 않은 경우 초기화 덤프(zabbix에 포함)에서 생성됩니다.
   • 시간대 목록이 생성됩니다(웹 인터페이스에 표시하는 데 필요함).
   • 현재 IP가 발견되어 이슈로 표시됩니다(콘솔에 로그인하라는 초대)
5. 초대가 변경됩니다. Ready to work라는 문구가 나타납니다.
6. 펌웨어를 사용할 준비가 되었습니다.

서비스 파일은 중요하며 시작 순서를 설정하는 파일입니다.

[Unit]
Description=restore system settings
Before=network.service prepare.service postgresql.service systemd-networkd.service systemd-resolved.service

[Service]
Type=oneshot
ExecStart=/usr/bin/settings_restore.sh

[Install]
WantedBy=multi-user.target

보시다시피 저는 스크립트가 먼저 작동하도록 종속성을 설치한 다음 네트워크가 가동되고 DBMS가 시작되도록 했습니다.

그리고 두 번째 서비스 (zabbix 준비)

#!/bin/sh
[Unit]
Description=monitor prepare system
After=postgresql.service settings_restore.service
Before=zabbix-server.service zabbix-agent.service

[Service]
Type=oneshot
ExecStart=/usr/bin/prepare.sh

[Install]
WantedBy=multi-user.target

여기서는 좀 더 복잡합니다. 시작은 multi-user.target에도 있지만 postgresql DBMS와 설정 복원을 시작한 후에 이루어집니다. 하지만 zabbix 서비스를 시작하기 전에.

logrotate를 위한 타이머 서비스

Systemd는 CRON을 대체할 수 있습니다. 진지하게. 또한 정확도는 분 단위가 아니라 초 단위까지입니다.(필요한 경우) 또는 이벤트의 시간 초과로 호출되는 단조로운 타이머를 만들 수도 있습니다.
내가 만든 기계의 시작부터 시간을 세는 단조로운 타이머였다.
2개의 파일이 필요합니다.
logrotateTimer.service - 서비스의 실제 설명:

[Unit]
Description=run logrotate

[Service]
ExecStart=logrotate /etc/logrotate.conf
TimeoutSec=300

간단합니다. 실행 명령에 대한 설명입니다.
두 번째 파일 logrotateTimer.timer는 타이머가 작동하는 위치입니다.

[Unit]
Description=Run logrotate

[Timer]
OnBootSec=15min
OnUnitActiveSec=15min

[Install]
WantedBy=timers.target

여기에 무엇이 있습니까?

• 타이머 설명
• 최초 시작 시간, 시스템 부팅부터 시작
• 추가 출시 기간
• 타이머 서비스에 대한 종속성입니다. 실제로 이것은 타이머를 만드는 문자열입니다.

종료 시 대화형 스크립트 및 종료 대상

또 다른 개발에서는 많은 작업을 수행하기 위해 자체 타겟을 통해 기계를 끄는 더 복잡한 버전을 수행해야 했습니다. 일반적으로 RemainAfterExit 옵션을 사용하여 원샷 서비스를 생성하는 것이 좋지만 이렇게 하면 대화형 스크립트를 생성할 수 없습니다.

그러나 사실 ExecOnStop 옵션으로 실행되는 명령은 TTY 외부에서 실행됩니다! 확인하기 쉽습니다. tty 명령을 붙여넣고 출력을 저장하세요.

따라서 목표를 통해 종료를 구현했습니다. 100% 정확하다고 주장하지는 않지만 효과가 있습니다!
수행 방법(일반적인 용어):
누구에게도 의존하지 않는 my_shutdown.target 타겟을 만들었습니다.
my_shutdown.target

[Unit]
Description=my shutdown
AllowIsolate=yes
Wants=my_shutdown.service 

이 대상으로 이동하면(systemctl isolate my_shutdwn.target을 통해) my_shutdown.service 서비스가 시작됩니다. 작업은 간단합니다. 즉 my_shutdown.sh 스크립트를 실행하는 것입니다.

[Unit]
Description=MY shutdown

[Service]
Type=oneshot
ExecStart=/usr/bin/my_shutdown.sh
StandardInput=tty
TTYPath=/dev/tty3
TTYReset=yes
TTYVHangup=yes

WantedBy=my_shutdown.target

• 이 스크립트 내에서 필요한 작업을 수행합니다. 유연성과 편의성을 위해 대상에 많은 스크립트를 추가할 수 있습니다.

my_shutdown.sh

#!/bin/bash --login
if [ -f /tmp/reboot ];then
    command="systemctl reboot"
elif [ -f /tmp/shutdown ]; then
    command="systemctl poweroff"
fi
#Вот здесь нужные команды
#Например, cp /home/user/data.txt /storage/user/
    $command

메모. /tmp/reboot 및 /tmp/shutdown 파일을 사용합니다. 매개변수를 사용하여 대상을 호출할 수 없습니다. 서비스만 가능합니다.

하지만 저는 작업의 유연성과 보장된 작업 순서를 얻기 위해 target을 사용합니다.

그러나 가장 흥미로운 것은 나중에 나왔습니다. 기기를 끄거나 다시 시작해야 합니다. 그리고 두 가지 옵션이 있습니다:

• 재부팅, 종료 및 기타 명령(여전히 systemctl에 대한 심볼릭 링크임)을 스크립트로 바꾸고 스크립트 내에서 my_shutdown.target으로 이동합니다. 그리고 대상 내부의 스크립트는 systemctl을 직접 호출합니다(예: systemctl 재부팅).
• 더 간단한 옵션이지만 마음에 들지 않습니다. 모든 인터페이스에서 shutdown/reboot/other를 호출하지 말고 대상 systemctl isolate my_shutdown.target을 직접 호출하십시오.

나는 첫 번째 옵션을 선택했습니다. systemd에서 재부팅(poweroff와 같은)은 systemd에 대한 심볼릭 링크입니다.

ls -l /sbin/poweroff 
lrwxrwxrwx 1 root root 14 сен 30 18:23 /sbin/poweroff -> /bin/systemctl

따라서 이를 자신만의 스크립트로 바꿀 수 있습니다.
재부팅

#!/bin/sh
    touch /tmp/reboot
    sudo systemctl isolate my_shutdown.target
fi

출처 : habr.com