[OCF] ocf-shellfuncs standardization - Comments? Objections?

[Alan Robertson]

Nick Stoughton wrote:
> On Wed, 2005-07-06 at 11:49, Ragnar Kjørstad wrote:
>>On Wed, Jul 06, 2005 at 08:56:32AM -0700, Nick Stoughton wrote:
>>>>>Well...that's overstating it more than a bit! The LSB definitely defines
>>>>>what things should do, and the 3.0 versions of the init script logging
>>>>>functions state that these functions should print a suitable message
>>>>>(doesn't say where though!)
>>>>Then that's not very useful is it?  I stand by my description - (even 
>>>>though it had a bit of hyperbole in it).
>>>>
>>>Thanks! See http://bugs.linuxbase.org/show_bug.cgi?id=1043 for the
>>>proposed corrective action here!
>>First, I don't understand _why_ the standard should specify this. Any
>>reason it could not be up to the implementations?
>>
> Why? Because it is unspecified to the point of uselessness!
> 
>>Second, if the standard specified how the logging functions should be
>>implemented, it would no longer be possible with alternative
>>implementations for e.g. sending the messages to the X console.
>>
>>So I think this proposed change is a step in the wrong direction.
>>
> 
> I'm quite open to alternative suggestions. But I would have thought that
> logging the message to the standard output was the best thing for your
> purposes ... this allows you to redirect it easily (including via use of
> constructs such as "exec > foo" to redirect all following output to a
> specified file) so that an RM can keep track (including redirecting all
> stdout to a Unix domain socket, or to the X console, for example).

I agree with ragnar on this one... Stdout is a problem for daemons, and 
these init script errors are special, as he points out.

I'm actually just getting my our project to fix some bugs caused by 
exactly such a stdout assumption - and in the end it is error prone, 
etc. [http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=475]

If you have them write to stdout, then the only way to capture it and 
look at it is to grab it with a pipe.  If you start the process with 
stdout directed to a pipe, then _that pipe will be by default inherited 
by all its child processes_.  Of course any daemon _should_ redirect 
stdout/stderr, etc.  But, often something is missed.

If the starting agent (like an HA system) tries to capture that with a 
pipe and then after the process exits, the starting agent closes the 
pipe, then the first time the daemon writes to stdout, it dies with SIGPIPE.

This is, of course, an error on the part of the daemon, but it's a very 
mysterious and hard-to-figure-out side-effect of that often-made error.

In our system we read stdout from a pipe for historical reasons, but I'm 
not that happy about it.  I certainly wouldn't wish it on anyone else :-).

Let's look at what we thought was a good thing on our ocf_log functions, 
and see if they'd be permissible (and I think they would) if transferred 
to our own local implementation of the log_success_msg, log_failure_msg 
and log_warning_msg functions (along with log_info and log_debug).

[[log_success is in practice definitely for the end of the operation 
declaring success.

log_failure is in practice definitely for the end of the operation 
declaring failure.

I say this because the Linux init systems print "starting xxx..." (no 
newline) and expect in practice one short phase to come out saying "ok" 
or "oops" or something like that.  And, the names of the functions 
reflect that understanding...
But, I'm going to ignore that for the moment...
]]

Here's what we do:
   prefix the message with
	CRIT, ERROR, WARNING, INFO or DEBUG
	the name of the script doing the logging
and possibly an instance name for the instance of the resource
	(identifying _which_ IP address or apache daemon, etc. was being
		operated on).

If this would be OK, and we added one for info and one for debug, then 
we could probably shift over to using the LSB names without any problem.

We want those functions to put the output _where it is needed_ - that is 
where the context, administrator, and HA software thinks it ought to go. 
  That might be stdout for some occasions, but not for others.

For example, in our implementation we send it to one of:
     our own non-blocking logging daemon (which sends it where its told
		including possibly syslog)
     syslog (which also sends it where it is told)
     a file specified by the administrator

If people think this is a reasonable idea, then I'd better cut a 
bugzilla on it, and do it pretty much immediately - because we're trying 
to start final-testing our first release implementing OCF resource agents.

A clarification:
  The ambiguity of the specification I was complaining about wasn't 
where it goes.  I was talking about more what would happen in practices 
if you used them more liberally than the vendors expected.

Nick:  If you would consider withdrawing or modifying your bugzilla to 
the LSB until we finalize our own discussion, that would be much 
appreciated.

-- 
     Alan Robertson <alanr at unix.sh>

"Openness is the foundation and preservative of friendship...  Let me 
claim from you at all times your undisguised opinions." - William 
Wilberforce