On Mon, Jun 11, 2007, Dan Cox wrote:
> A few peculiarities with the OpenPKG run control system are causing some end
> user confusion when working with services. (Using openpkg-20070608)
>
> Currently, the system boot init script for OpenPKG is executing 'rc all
> start'. This results in the %start section getting executed for all scripts
> regardless of the enable/disable setting.
>
> It is then left up to each individual init script to exit out before doing
> any work if it's currently disabled. This results in counterintuitive
> behavior when working with individual services. For example, consider the
> following:
>
> # openpkg rc openssh start
> OpenPKG: start: openssh.
>
> The impression is given that the service appears to have started, when in
> fact it has not because it's disabled:
>
> # openpkg rc openssh status
> OpenPKG: status: openssh.
> openssh_enable="no"
> openssh_usable="unknown"
> openssh_active="no"
>
> Likewise, calling 'openpkg rc openssh stop' does not result in stopping the
> service, even if it's running for whatever reason.
>
> 'openpkg rc openssh status' is even more confusing. If the service happens
> to be running and is then disabled, the status command will report that the
> service is not active, which is certainly inaccurate.
>
> Another issue is that during system shutdown openpkg calls 'rc all stop',
> which executes all of the %stop sections in all scripts. Unfortunately, the
> %stop sections exit out doing no work if the service is currently marked as
> disabled. This results in unclean shutdowns for services that may have been
> running, which were set to disabled at some point.
>
> Standard UNIX init systems allow you to start/stop/status services
> regardless of the fact they may or may not be enabled for system boot.
Yes, all of the above I can fully confirm.
> It would seem to me that a more standard behavior might be achieved by
> removing the enable/disable tests from the start/stop/status sections of
> init scripts.
> Then change 'rc all start' on system boot to only execute the %start section
> of scripts which are currently enabled. For shutdown, 'rc all stop' would
> still execute %stop sections for all scripts; however we leave in the
> 'active no' tests in the individual init scripts to determine if work needs
> to be done.
>
> Thoughts/comments?
Well, the current OpenPKG rc facility is still based on the major
design assumption that the "rc" frontend script itself is a simple
driver/wrapper while the "rc.xxxx" backend scripts do all the complex
work in generic %xxx sections. When I decided for this design in 2001
I thought this gives us maximum flexibility and that this flexibility
in the long term is really required. After having packaged over 1000
applications from scratch I really have to admit that we _never_ needed
such a lot of flexibility. Ok, I could not have known this initially,
but today I also would implement the "rc" facility in a less generic
and more specific way (the %xxx sections have a hard-coded meaning) and
especially let the frontend driver manage the complete logic.
Remains just the subtle point: _who_ volunteers to rewrite the "rc"
system from scratch (or ports Solaris SMF or whatever modern facility
over to OpenPKG) or at least hacks the existing "rc" facility to resolve
a few of the above issues? For a rewrite, btw, today one would prefer
to use at least "miniperl" or even a C program. In the OSSP CVS there
is actually a C version of C from Michael Schloh. Unfortunately this
project was never 100% finished and hence never adopted for use inside
OpenPKG...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
