init service failing to enable once a systemd service file is generated

cancel
Showing results for 
Search instead for 
Did you mean: 
FirstMelon
Member II

init service failing to enable once a systemd service file is generated

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[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.

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 Prepaid Card Status :

# 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.