systemd 환경에서 sysVinit 서비스를 시작할 때 정상적으로 온라인 상태가 되지 않는 문제를 해결하고 있습니다. /etc/systemd/system/해당 서비스에 서비스 파일이 없거나 재정의하면 자동으로 올바르게 시작되는 것으로 나타났습니다 . 이 경우 systemd는 시스템에 존재하는 "레거시" sysvinit 스크립트를 읽어서 시작 스크립트를 동적으로 로드해야 한다고 이해하고 있지만 이에 대해 100% 명확하지는 않습니다.
내가 혼란스러워하는 점은 해당 서비스의 systemctl에 edit --full 옵션을 전달하면 플랫 파일이 생성되고 /etc/systemd/system/해당 서비스가 이제 부팅 시 자동으로 시작되지 않는다는 것입니다. 편집 옵션을 사용하고 재정의를 추가하려고 하면 서비스가 시작되지 않는 것 같습니다.
필요한 경우 아래 예를 참조하세요.
시스템 작동 방식의 예
이 경우 "ProgramExample"이라는 서비스(Centos)에는 /etc/init.d/programexample및 에 init 스크립트가 있습니다 /etc/rc.d/init.d/programexample.
# ls -l /etc/rc.d/init.d/programexample
-rwxr-xr-x. 1 root root 2264 Mar 29 14:11 /etc/rc.d/init.d/programexample
서비스 파일이 없습니다 /etc/systemd/system/.
# ls -lh /etc/systemd/system/programexample.service
ls: cannot access /etc/systemd/system/programexample.service: No such file or directory
이 구성의 Systemctl 상태 출력은 다음과 같습니다.
# systemctl status programexample.service
● programexample.service - LSB: Start Program Example at boot time
Loaded: loaded (/etc/rc.d/init.d/programexample; bad; vendor preset: disabled)
Active: active (exited) since Wed 2017-03-29 15:53:06 CDT; 14min ago
Docs: man:systemd-sysv-generator(8)
Process: 1297 ExecStart=/etc/rc.d/init.d/programexample start (code=exited, status=0/SUCCESS)
Mar 29 15:53:05 centos7-box systemd[1]: Starting LSB: Start ProgramExample at boot time...
Mar 29 15:53:05 centos7-box su[1307]: (to programexample) root on none
Mar 29 15:53:06 centos7-box programexample[1297]: ProgramExample (user programexample): instance name set to centos7-box
Mar 29 15:53:06 centos7-box programexample[1297]: instance public base uri set to https://192.168.0.148.programexample.net/programexample/
Mar 29 15:53:06 centos7-box programexample[1297]: instance timezone set to US/Central
Mar 29 15:53:06 centos7-box programexample[1297]: starting java services
Mar 29 15:53:06 centos7-box programexample[1297]: ProgEx server started.
Mar 29 15:53:06 centos7-box systemd[1]: Started LSB: Start ProgramExample at boot time.
위의 구성을 사용하면 /etc/systemd/system/에 파일을 생성/배치할 필요가 없으며 ProgramExample 서비스가 자동으로 정상적으로 시작될 수 있습니다.
systemctl edit --full한 번 (또는 하나만) 사용 :edit
systemctl에 편집 내용을 전달한 후 다음을 관찰했습니다.
- 플랫 파일 또는 오버레이 디렉터리는 /etc/systemd/system/에 배치됩니다.
- 문제의 서비스(이 경우 ProgramExample)는 부팅 시 시작할 수 없습니다.
- systemctl을 사용하여 해당 서비스를 "활성화"할 수 없습니다.
이 구성의 Systemctl 상태 출력(편집 후):
# systemctl status programexample.service
● programexample.service - LSB: Start ProgramExample at boot time
Loaded: loaded (/etc/rc.d/init.d/programexample; static; vendor preset: disabled)
Active: inactive (dead)
Docs: man:systemd-sysv-generator(8)
/etc/systemd/system/옵션을 사용할 때 생성되고 배치되는 서비스 파일입니다 edit --full.
# Automatically generated by systemd-sysv-generator
[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/rc.d/init.d/programexample
Description=LSB: Start ProgramExample at boot time
Before=runlevel2.target
Before=runlevel3.target
Before=runlevel4.target
Before=runlevel5.target
Before=shutdown.target
Before=adsm.service
After=all.target
After=network-online.target
After=postgresql-9.4.service
Conflicts=shutdown.target
[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/rc.d/init.d/programexample start
ExecStop=/etc/rc.d/init.d/programexample stop
ExecReload=/etc/rc.d/init.d/programexample reload
여기서 무슨 일이 일어나고 있는 걸까요? /etc/systemd/system/ 및/또는 서비스 오버레이 디렉토리에 플랫 서비스 파일이 없으면 systemd가 해당 서비스의 init 스크립트에서 이 정보를 동적으로 읽는다는 점을 수정합니까? /etc/systemd/system/에서 서비스 파일을 편집하고 기본 파일을 그대로 두는 작업을 여러 번 시도했지만 자동 시작이 작동하지 않거나 서비스가 "활성화" 상태로 전환되지 않습니다.
호환성 및 동시성 이유로 인해 systemd에 의존하여 init 스크립트 LSB 헤더에서 읽는 것보다 systemd 구성을 위한 systemd .service 파일을 제공하는 것이 더 낫다고 생각합니다. 그러나 systemd에서 생성된 기본 파일은 시작되지 않거나 다른 많은 파일과 함께 작동하지 않습니다. 함께 시도한 .service 파일을 더 간단하게 반복할 수 있습니다.
답변1
이제 문제는 systemd-sysv-generator에 의해 자동으로 생성된 서비스 파일에 WantedBy 옵션이 포함된 설치 부분이 없다는 것입니다. 서비스를 올바르게 활성화할 수 있도록 생성된 파일 /etc/systemd/system/programexample.service에 다음을 추가했습니다.
[Install]
WantedBy = multi-user.target
그 뒤를 쫓아 달려갔어
systemctl daemon-reload
systemd가 내 서비스 파일을 읽는지 확인하세요.
이제 내 서비스가 실제로 "활성화"될 어딘가에 심볼릭 링크되어 있다는 적절한 알림을 받습니다.
[root@centos7-box ~]# systemctl enable programexample.service
Created symlink from /etc/systemd/system/multi-user.target.wants/programexample.service to /etc/systemd/system/programexample.service.
이 링크서비스 파일을 더 잘 이해할 수 있도록 도와주세요.
systemd-sysv-generator에 기본적으로 WantedBy 옵션이 있는 설치 섹션이 포함되어 있지 않다는 점이 마음에 들지 않습니다. systemd가 LSB 헤더를 동적으로 읽고 부팅 시 서비스를 올바르게 시작할 수 있다면 그에 따라 서비스 파일을 생성하지 않는 이유는 무엇입니까? 나는 systemd가 성장통에 직면할 것으로 예상된다고 생각합니다.
2020년 7월 7일 업데이트됨:
Debian Buster로 작업하고 SysVInit 레거시 서비스를 활성화하려고 시도하는 동안 2017년에 이 문제를 처리할 때 시간을 절약할 수 있을 것이라고 생각하는 다음과 같은 멋진 메시지를 받았습니다.
Synchronizing state of programexample.service with SysV service script with
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable programexample
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or
.requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
답변2
내 경우에는 내 시스템에 2개의 서로 다른 Java 버전이 있어서 문제가 발생했습니다. 그 중 하나(Oracle JDK)가 나중에 내 시스템의 jenkins에 설치되었습니다. 나는 Alternatives -config java 명령을 실행하고 java를 jenkins와 함께 설치된 공개 jdk 버전으로 설정했습니다. Jenkins 서버 서비스를 다시 시작합니다. 그게 다야.