OPNsense Forum
English Forums => Development and Code Review => Topic started by: 8191 on December 13, 2015, 07:43:16 pm
-
Hi,
what's the recommended way to stop services using configd? Keeping in mind, that rc script refuse to work if the corresponding service is not enabled, simply executing /usr/local/etc/rc.d/<service> stop is not sufficient.
In the Proxy plugin is was done by calling killall squid after trying to execute the rc.d/squid stop, but why did you actually use killall to "stop" squid instead of executing /usr/local/etc/rc.d/squid onestop? Is there a side-effect in using the "onestop" action? I'd say a completely clean mechanism should not kill all instances, but should only kill the instance stored in the service's pid-file...
Also for querying the service status, maybe using "onestatus" instead of "status" would allow recognizing e.g. a hanging or still running process, even the service has already been disabled. Right now if the service is not enabled, OPNsense always assumes that the process behind the service is not running, which is fact is not always the case.
Thanks,
Manuel
-
Hi Manuel,
For as far as I know there is no issue with using the onestop action, but squid had an issue which resulted in an automatic restart after it was stopped the normal way.
We choose to add the killall to make sure it can't restart on stop.
I think it's a good idea to change the configd calls to the one[status|stop] actions, it certainly will fix some race conditions and faulty statuses.
Regards,
Ad
-
Hi Manuel,
Eventually, we want to have this: https://github.com/opnsense/core/issues/412
The rationale from the top of my head is something like this:
o OPNsense must to use the rc system of the service and wrap configd around it if available (see ticket)
o If an rc script is not available for a service, it must still provide commands for consistency (also ticket)
o Any outside service should still be able to use /etc/rc.conf without interference (note that FreeBSD also has the convenient "service" command utility wrapper).
o Managed services and manual services for the same service / binary cannot coexist (rather killall vs. kill by pid). This is a problem of unknown complexity. We should rather consider to include use cases users try to achieve with this and integrate them directly via the GUI or the author knows what he is doing and is not interested in sharing the use case (for reasons that can include lack of interest; the burden of it not clashing with OPNsense now or in the future is with the author then).
o For lightweight and persistent user scripting (and our plugin system as well) even on firmware upgrade, we've also added the /usr/local/etc/rc.syshook.d/ mechanics to allow users to add automatic runtime scripts that don't require her to write complicated rc scripts. rc.syshook currently supports three types of hooks, one for system startup "FILENAME.start" (normal network daemon), one for early system startup "FILENAME.early" (kernel drivers, especially for network drivers), and "FILENAME.stop" which is executed on halt / reboot (mostly unused, but it could harbour backup scripts). Further work here would include periodic scripts like "FILENAME.hourly", "FILENAME.daily" and "FILENAME.weeky" for backup features or other system events. But we like to keep it small any only add support when an actual use case arises that makes sense.
Hope that helps,
Franco
-
Thanks for your responses, Ad, Franco.
I agree with your point of view on the topic, but would like to add something regarding
Managed services and manual services for the same service / binary cannot coexist (rather killall vs. kill by pid).
The reason why I prefer killing specific PIDs rather than a bunch of processes is not that managed and unmanaged services can coexist, but more that some services for instance use forking mechanisms (I recall Apache httpd right now, for instance) to distribute requests or implement a (weird) service architecture. When killing these processes starting maybe with a random child-process, the service will very sure not shutdown gracefully.
Regards,
Manuel
-
You're right, the topics are orthogonal.