[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: initscript policy proposal



On Mon, 06 Nov 2000, Paul Slootman wrote:
> Nowhere in policy do I see that it is forbidden to pass extra
> parameters. However, your invoke-rc.d does in fact explicitly
> forbid it (it prints an error and exits with 103).

You're right. I'll change the interface and implementation for invoke-rc.d.

However, do note that *only* the first "initscript parameter" will be
recognized as an action, and everything else will be sent to the initscript
*as is*. Also, should any sort of fallback action happen (because of
policy-rc.d or something else), the action (first initscript parameter) will
be changed but the other "extra parameters" will remain the same.

I don't think I can do much better than this, as policy (and practice,
AFAIK) defines only the first parameter.

> I can think of a situation where a package may have more than
> one daemon, and upon upgrading only one of those daemon must
> be restarted. Calling the init.d script with the parameters
> "restart daemonname" might be a very useful solution, one that
> is not possible with your current scheme.

If I came across such a package, I'd probably file a wishlist bug
complaining that separate initscripts allow for more fine-tuned
administrator control (unless it makes absolutely no sense to start one
daemon and not start the other, or something).

Which is no reason not to support the 'extended usage' you suggest, anyway.
I wouldn't recommend adding such extra parameters to an initscript, though.
That's uncharted territory AFAIK.

> > ## sanity checks and just-in-case warnings.
> > case ${ACTION} in
> >     start|stop|force-stop|restart|restart-if-running|reload|force-reload|status)
> > 	;;
> >     *)
> > 	printerror action ${ACTION} is unknown, but proceeding anyway.
> > 	;;
> > esac
> 
> Here you test for unknown actions, and continue anyway. Not very
> consistent with the exit 103 above?

Yes, it is consistent. I think I explained this warning somewhere, but here
it is again: "unknown" actions are not wrong, and not discouraged. However,
there's no guarantee that policy to avoid out-of-runlevel service starts,
and policy-rc.d enforced configuration will be able to be sanely (as in
consistent with policy the local administrator fed to policy-rc.d) applied
to an unknown action. So, a warning to the user is sent, but the action is
carried anyway.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Attachment: pgpZTBH9pKva7.pgp
Description: PGP signature


Reply to: