Hi, scl tools from scl-utils package uses "system()" call which calls fork() internally. That breaks spawning of daemons from systemd service file if the daemon use sd_notify (Type=notify) systemd feature. I propose using exec instead of system() which does not fork and should fix this issue. I'm attaching my original email as reference and more detailed description of problem: When you use "/sbin/service" to start the httpd24-httpd, environment variables are cleared. This obviously clears LD_LIBRARY_PATH change done by enabling ruby193 SCL, so when mod_passenger executes ruby later, ruby fails because it can't load its shared libraries. Similar problem also exists in case when you want to start httpd24 with ruby193 on boot. You have to somehow configure that ruby193 SCL has to be enabled before starting httpd24-httpd. Mariadb had the same problem and fixed it by executing (using wrapper, but that doesn't matter) '/usr/bin/scl enable $NEEDED_COLLECTIONS "daemon"' as their ExecStart script. This is OK if your daemon does not use Type=notify. In the case of Type=notify, systemd expects sd_notify() call from the daemon to get its MAINPID and various statistics showed in "systemctl status" output. Only the first process spawned by systemd can call sd_notify and finish startup. And this is where the problem is. The first process spawned by systemd is "scl" process, which creates bash script and executes it using system() call. system() calls fork() and therefore httpd will be executed with new PID and won't be able to call sd_notify() successfully (because it's called in the process with different PID than the very first one executed by systemd). Systemd then thinks httpd did not start and fails. Systemd can be configured to accept sd_notify call from any process in cgroup, but that's not possible solution for httpd because of security risks (cgi scripts should not have opportunity to call sd_notify successfully). If you see some possible solutions (patching "scl" to not call system() for example), please share.
(In reply to Jan Kaluža from comment #0) > Systemd can be configured to accept sd_notify call from any process in > cgroup, but that's not possible solution for httpd because of security risks > (cgi scripts should not have opportunity to call sd_notify successfully). > > If you see some possible solutions (patching "scl" to not call system() for > example), please share. First, I've realized that there is not only one fork (from system() call), but rather one more fork done by bash script (httpd call in the enable scriptlet, copied into /var/tmp) -- but it seems to be quite easy to solve, since we can use something like: ExecStart=/usr/bin/scl enable httpd24 -- exec /opt/rh/httpd24/root/usr/sbin/httpd $OPTIONS -DFOREGROUND (note the "exec" call instead of pure httpd command) More as a brainstorming, there can be some other ways how to solve this particular httpd issue -- either changing the process to forking (it doesn't seem to me like notify is necessary; it only adds some functionality, right?) or use some work-around to not use scl command (but only using rpath doesn't seems to be sufficient). Some wild idea how can we avoid to call scl utility is to run `scl enable httpd24 store_my_env` in a ExecStartPre, which would store only necessary environment variables into a file, and such file will then be parsed in the beginning of httpd process. Well, hacky enough, but still better than pure rpath, IMHO.
I agree, we should be able to use systemd features. Would it be a problem to change system call to exec?
(In reply to Marcela Mašláňová from comment #4) > I agree, we should be able to use systemd features. Would it be a problem to > change system call to exec? +1 Even if httpd vs. ruby issue could be solved by rpath/runpath and it would probably work fine, I'd rather see some conceptual solution for any other cases where rpath/runpath won't be enough. OTOH, this issue is quite specific (only valid for systemd services with NotifyAccess=main).
Upstream ticket: https://fedorahosted.org/SoftwareCollections/ticket/11
*** Bug 1030929 has been marked as a duplicate of this bug. ***
scl-utils-2.0-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/scl-utils-2.0-2.fc20
scl-utils-2.0-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/scl-utils-2.0-2.fc21
Package scl-utils-2.0-2.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing scl-utils-2.0-2.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-0479/scl-utils-2.0-2.fc21 then log in and leave karma (feedback).
scl-utils-2.0.1-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/scl-utils-2.0.1-1.fc21
scl-utils-2.0.1-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/scl-utils-2.0.1-1.fc20
scl-utils-2.0.1-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
scl-utils-2.0.1-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.