Description of problem: "service ypbind start" claims to start ypbind, but doesn't. Version-Release number of selected component (if applicable): systemd-9-3.fc15.x86_64 How reproducible: every time I tried. Steps to Reproduce: 1.Boot system. Notice that I can't log in because ypbind is not running. 2.Attempt to start ypbind. It says ok, but still no ypbind. 3.log in as root and run "sh /etc/init.d/ypbind start" to start ypbind by hand. 4. now I can log in. Actual results: says ok, but no ypbind. Expected results: ypbind starts. Additional info: worked fine with upstart.
Any errors in /var/log/messages?
The ypbind initscript calls 'status' to see whether to actually start. (Not sure it should do this, but it's not something we should out-and-out break.) Now that starting ypbind is redirected to systemctl, the status() algorithm is returning the original script invocation as a ypbind process. So it thinks it's running, and doesn't start. (FWIW, this ends up confusing systemd's sysv support as to the current status of ypbind.)
The simplest way to 'fix' this would be to remove '-x' from the pidof calls in init.d/functions. But this would break any sysv script that is actually trying to check the status of a shell/python/perl/etc. script, which is a regression that I don't want to introduce. An ugly fix would be to add an option to pidof that excludes things with the same execution environment (shell & script) of pidof's $PPID. That's gross, but should DTRT.
Another potential fix would be for systemd to somehow pass in the pid of the script that called systemctl, and act on that. Not sure that's practical.
One more potential solution: have the redirect exec systemctl instead of invoking it. This is going to mean that all stop/start/etc. commands become much much less verbose.
The ugly fix in comment #4 is probably the most correct, as it's the only one that fixes the existing-even-with-upstart bug of two concurrent 'service <foo> status' calls returning each other.
systemd-9-3.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14
initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts sysvinit systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14
systemd-10-1.fc14, initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd initscripts sysvinit'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-10-1.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14
initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-10-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.