Background: Services that use the Gentoo init scripts often report a status of [started] or [OK] even though they fail to start. The most recent bug like this that I've found is with snort. If you have a bad rule, snort will initialize, the rc-scripts will give it an [OK] status, and then it will die once it parses the scripts. The real problem is not that the daemons don't return errors, but that our init scripts do not make reasonable attempts to verify service startup. If a Gentoo init script claims that a service started, it should make an effort to check that the processes are actually running shortly after a daemon starts, even if start-stop-darmon says the parent process initialized. I am aware that there are services that can monitor the status of other services (app-admin/mon?) but I think this issue is a little different. If an ebuild developer knows that an error condition can commonly occur shortly after a daemon initializes, why not attempt to catch those errors? I propose increasing developer awareness of this problem, perhaps through some formal guidelines for ebuild developers. At the very least, I would like to see these bugs being acknowledged in bugs.gentoo.org instead of getting the same old upstream/it's not our fault response. We are responsible for our init scripts, and they are important to our users. Reproducible: Always Steps to Reproduce: 1. 2. 3.
as you point out, this is a per-package issue should be brought up on gentoo-dev; bugzilla generates little 'awareness' of issues
Or file a bug against snort/whatever with a patch if possible.
