RHEL7 and SUSE12 packages rely on the sysvinit->systemd compatibility layer. These processes start and stop MongoDB using the init script but the process is managed, to some extent, by systemd. As I understand it, the installation and upgrade process for RPM packages do not keep track of the state of the program, and as a result, there's no reliable or supported upgrade path that includes transitioning between init systems. As a result RHEL7 and SUSE12 packages will continue to use the sysvinit compatibility system.

Kanstantsin Shautsou
added a comment - Jun 07 2016 07:58:39 PM +00:00 - edited
RHEL7 and SUSE12 packages rely on the sysvinit->systemd compatibility layer. These processes start and stop MongoDB using the init script but the process is managed, to some extent, by systemd. As I understand it, the installation and upgrade process for RPM packages do not keep track of the state of the program, and as a result, there's no reliable or supported upgrade path that includes transitioning between init systems. As a result RHEL7 and SUSE12 packages will continue to use the sysvinit compatibility system.
http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html#S3-RPM-INSIDE-PREUN-SCRIPT and https://fedoraproject.org/wiki/Packaging:Scriptlets
Sysv script is really unreliable, it redirects any errors into dev/null. And the only one single sysv script that i have on all servers today. Would be very glad if el7 packaging would stop shipping it.
Is there anything i can help with?

I experience problems on CentOS7 with the sysvinit compability generators. As quickfix I simply copied the broken systemd generated file and manually fixed and copied it into the right place. The problem was with over 100 PHP-FPM pools the After= statement would be so long it somehow resulted strange issues.

Ramon Fernandez
added a comment - Jul 30 2016 12:54:32 PM +00:00 Ewald van Geffen , can you please open a separate ticket and provide the diff of the changes you made? That will help investigating this issue.
Thanks,
Ramón.