I've been troubleshooting an issue with a sysVinit service not coming online properly at boot within a systemd environment. What I've found is that when no service file or overrides are present in /etc/systemd/system/ for the said service, it autostarts properly. In this case, as I understand it, systemd should be dynamically loading the startup script via reading "legacy" sysvinit scripts present on the system, although I'm not 100% clear on that.
What I'm confused about is that as soon as I pass the edit --full option to systemctl for said service, a flat file is generated at /etc/systemd/system/ and said service now fails to autostart at boot. Using the edit option and trying to add any overrides also seems to cause the service to fail to boot.
Examples, if needed, provided below...
Example of the system when it works:
The service, in this example called "ProgramExample" has an init script placed in /etc/init.d/programexample and also /etc/rc.d/init.d/programexample:
[root@centos7-box ~]# 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
No service file present at /etc/systemd/system/:
[root@centos7-box ~]# ls -lh /etc/systemd/system/programexample.service ls: cannot access /etc/systemd/system/programexample.service: No such file or directory
Systemctl status output in this configuration:
[root@centos7-box ~]# 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: Starting LSB: Start ProgramExample at boot time... Mar 29 15:53:05 centos7-box su: (to programexample) root on none Mar 29 15:53:06 centos7-box programexample: ProgramExample (user programexample): instance name set to centos7-box Mar 29 15:53:06 centos7-box programexample: instance public base uri set to https://192.168.0.148.programexample.net/programexample/ Mar 29 15:53:06 centos7-box programexample: instance timezone set to US/Central Mar 29 15:53:06 centos7-box programexample: starting java services Mar 29 15:53:06 centos7-box programexample: ProgEx server started. Mar 29 15:53:06 centos7-box systemd: Started LSB: Start ProgramExample at boot time.
With the above configuration, without any files created/placed in /etc/systemd/system/, the ProgramExample service autostarts properly.
Once systemctl edit --full (or just edit) is used:
Once any edits are passed to systemctl, I have observed the following:
- A flat file or an override directory will be placed in /etc/systemd/system/
- Said service, in this case ProgramExample, fails to start at boot.
- I will be unable to "enable" said service using systemctl
Systemctl status output in this configuration (post edit):
[root@centos7-box ~]# 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)
This is the service file that is being generated and placed in /etc/systemd/system/ when using the -edit --full option:
# 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
What is happening here? Am I correct that without the flat service file and/or service override directory in /etc/systemd/system/ that systemd is dynamically reading this information from said service's init script? I've tried numerous iterations of editing the service file at /etc/systemd/system/ and leaving the default file in place and cannot get autostarting to work or the service to go into an "enabled" state.
I believe it would be preferable to have a systemd .service file for systemd configurations instead of relying on systemd to read from init script LSB headers for compatibility and concurrency reasons but the default file systemd is creating is failing to start or enable along with numerous other more simple iterations of the .service file I've attempted.