[RFC] make bb_[p]error_msgXXXX() functions able to direct output to syslog

[Tito]

On Sunday 3 September 2006 17:41, Denis Vlasenko wrote:
> On Sunday 03 September 2006 17:01, Tito wrote:
> > On Sunday 3 September 2006 15:52, Bernhard Fischer wrote:
> > > On Sun, Sep 03, 2006 at 02:39:55PM +0200, Denis Vlasenko wrote:
> > Hi,
> > There is bb_syslog + sulogin cleanup  patch pending and waiting for
> >  rob's review that maybe is interesting in this case:
> > 
> >          void bb_msg_and_syslog(int level, const char *fmt, ...)
> 
> This won't help with xopen(). If we are daemonized, xopen()
> should direct error message to syslog. Thus, we want
> bb_[p]error_msgXXX (which is called internally by xopen)
> to do it, not some new function.
> 
> If we are not daemonized, we should not log anything,
> but print it to stderr.
> 
> Double logging (stdout and syslog) looks like not that
> useful in real life. We are either daemonized or not,
> not both.
> 

We are doing this all the time, if you grep through the source
you will see that most of the calls to syslog goes together
with a bb_*error_msg_*  or printf function printing a somewhat modified
message to stdout/stderr. 
The idea behind it was not involving daemonization
at all, just remove duplicated similar messages.
So to address your xopen example maybe:

if (open(x))
	bb_msg_and_syslog(LOG_ERR, "Can't open %s", x);

could be a solution? 

I know that it doesn't use the xfunc but avoids
msg duplication as you have to feed some kind of msg
to syslog anyway and by choosing the wording
carefully we could fullfill both purposes.
On the same time it will printf to std* if not daemonized
and also log. 

> 
> Every time I work with this, I feel this "log level" idea
> is a bad design. It simply does not work right in practice. 

The log level was the only steering wheel I had in this case.
We can wrap something around it but this would create a
hell of combinations, at least:

bb_msg_and_syslog()
bb_err_msg_and_syslog()
bb_err_msg_syslog_and_die()

and the respective no_msg variants.

> I prefer "seriousness" of the message to be encoded in the name
> of the function: bb_XXXerrorXXX is error, bb_XXXwarningXXX is warning.
> For stdout/err, it affects whether we print to stdout or stderr.
> For syslog, it chooses log level:
> 
>            std     syslog
> debug      stderr  LOG_DEBUG
> info       stdout  LOG_INFO
> warning    stderr  LOG_WARNING
> error      stderr  LOG_ERR
> 
> LOG_NOTICE, LOG_CRIT, LOG_ALERT, LOG_EMERG are just silly.

Ok, so we can restrict them basically to 2 level-flags,
if think of LOG_DEBUG as USE_DEBUG(LOG_INFO.......)

LOG_INFO                              printf   + syslog
LOG_ERR                               bb_error_msg + syslog

and maybe add

LOG_ONLY                            only syslog

and

LOG_DIE                                exit(EXIT_FAILURE);

bb_msg_and_syslog(LOG_ERR|LOG_ONLY|LOG_DIE, "Pippo Pluto Topolino");

Could give enough information to the programmer about what we are doing.

> xxx_and_die() works wonderfully. compare that with "LOG_ERR, LOG_CRIT,
> LOG_ALERT, LOG_EMERG" rule from above.
> 
> > 	You can disable messages by adding LOG_ONLY (100) to the other LOG_* values.
> > 
> > 	So by choosing an appropriate level value we can influence the behaviour
> > 	of the function.
> --
> vda
> 

Tito