Hi Jordan, Le 20 mars 08 ? 17:49, Jordan Brown (Sun) a ?crit : >> (...) > (...) > That seems to compare pretty favorably to a "traditional" mechanism. > Not that a traditional start script is all that hard, but a > traditional kill script is harder, since you have to track a pid > (and are you sure that pid still belongs to your daemon?) or hunt > down instances of your daemon with pgrep (and are you sure there > aren't any false matches?). > > Of course, this is a very minimal service, but that's what you asked > for. If you want to express dependencies, it's a little more > complicated (but then in a traditional configuration we'd have to > talk about where to put the script in the S* and K* sequences). If > you want to include configuration information, that too is more > work, but so it would be in a traditional configuration. If you > want to properly track whether the service came up, that's a bit > harder... but again, it'd be harder in a traditional environment, > and here there's a clear mechanism for reporting and handling the > failure. > > Yes, it's very _different_ from the traditional mechanism, but in an > absolute sense is it _harder_?
Nice shot ! I like your demonstration. > Note that even in this minimal example, you get significant gains > over a traditional installation: > > - Your service is visible in service lists. > - Its output is logged in an organized way. > - The administrator can enable and disable it. > - If the administrator manually enables it, it gets the standard > environment, not the administrator's personal environment. > - There's zero risk of hitting the wrong program when you kill it. > - It starts in parallel with other services, for better boot > performance. > - It's automatically restarted if it dies. > > (Note to SMF core team: This could be a bit simpler still. Have > defaults for more of the attributes. The default for the "type" > attribute on <service> could be "service". The default for the > "type" attribute on exec_method could be "method". I wonder whether > the various types of service_bundle would be better done as > different element names, eliminating the "type" attribute. Can > there be a default for timeout_seconds? Perhaps the stop method > could default to :kill.) Two supplementary notes : - add samples into man...something like this Jordan's demonstration - what about write a "RH service translator" which use Red Hat style headers in rc scripts to convert it to a manifest/method ? Nicolas
