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/programexampleNo service file present at /etc/systemd/system/:[root@centos7-box ~]# ls -lh /etc/systemd/system/programexample.servicels: cannot access /etc/systemd/system/programexample.service: No such file or directorySystemctl 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 noneMar 29 15:53:06 centos7-box programexample[1297]: ProgramExample (user programexample): instance name set to centos7-boxMar 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/CentralMar 29 15:53:06 centos7-box programexample[1297]: starting java servicesMar 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 systemctlSystemctl 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/programexampleDescription=LSB: Start ProgramExample at boot timeBefore=runlevel2.targetBefore=runlevel3.targetBefore=runlevel4.targetBefore=runlevel5.targetBefore=shutdown.targetBefore=adsm.serviceAfter=all.targetAfter=network-online.targetAfter=postgresql-9.4.serviceConflicts=shutdown.target[Service]Type=forkingRestart=noTimeoutSec=5minIgnoreSIGPIPE=noKillMode=processGuessMainPID=noRemainAfterExit=yesExecStart=/etc/rc.d/init.d/programexample startExecStop=/etc/rc.d/init.d/programexample stopExecReload=/etc/rc.d/init.d/programexample reloadWhat 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. 
init service failing to enable once a systemd service file is generated
systemd;services;sysvinit;autostart
I've now found that the issue was that the service file automatically generated by systemd-sysv-generator lacks an install section with a WantedBy option.  I added the following to my generated file at /etc/systemd/system/programexample.service  which allowed me to properly enable the service:[Install]WantedBy = multi-user.targetAfter that I ran systemctl daemon-reloadto ensure my service file was read by systemd.  Now I received a proper notification that my service was actually symlinked somewhere to be enabled:[root@centos7-box ~]# systemctl enable programexample.serviceCreated symlink from /etc/systemd/system/multi-user.target.wants/programexample.service to /etc/systemd/system/programexample.service.This link helped me better understand the service file.  I am not a fan of the way that systemd-sysv-generator does not include an install section with a WantedBy option by default.  If systemd can dynamically read the LSB headers and properly start services at boot, why doesn't it generate the service file accordingly?  I suppose some systemd growing pains are to be expected.  