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

Tito farmatito at tiscali.it
Sun Sep 3 18:02:28 UTC 2006


On Sunday 3 September 2006 19:25, Denis Vlasenko wrote:
> On Sunday 03 September 2006 18:49, Tito wrote:
> > 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. 
> 
> I'd say ~50% of syslog() calls do this. Okay, you convinced me.
> Some applets do need to send output to stderr and to syslog.
> 
> > 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.
> 
> I prefer:
> 
> 	bb_logmode = LOGMODE_BOTH;
> 	...
> 	xopen(...); /* will output error to stderr & to syslog */

So you will need to reset this multiple times in the same app:

bb_logmode = LOGMODE_BOTH;
msg(a)
bb_logmode = LOGMODE_*;
msg(b)
bb_logmode = LOGMODE_BOTH;

etc.

maybe a size increase!?!

I can agree on something like this for
int bb_facility = LOG_USER; (or LOG_DAEMON)
as this will be set just once per app, but
logmode maybe could change multiple times?

> > > 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.
> 
> no_msg variants are only useful for perror, which are in turn error
> only (not warning/info) - those already exist.
> So in the end you do not need to add more xxx_no_msg_xxx.
> 
> xx_and_syslog is covered by bb_logmode, no need for those too.
> 
> As I already said in the other mail, it looks like we will
> cover a lot of cases with just four additional functions:
> 
> void bb_warning_msg(const char *s, ...)
> void bb_vwarning_msg(const char *s, va_list p)
> void bb_info_msg(const char *s, ...)
> void bb_vinfo_msg(const char *s, va_list p)
> 
> With bb_logmode = { LOGMODE_STDIO, LOGMODE_SYSLOG, LOGMODE_BOTH }
> you should be happy too. No?

I am... ;-)
the fact is that probably we are looking for different goals
and started with different premises.
If I understand it correctly
you) want to embed syslog features in xfuncs  and toggle them on/off with bb_logmode
i) want to add a function that takes care of msg string duplication when bb_msg_* and syslog are used one after the other

Maybe after this opinion exchange we can create something that satisfies us both.
Your idea with bb_logmode is good but I'm obsessed by flexibility......

An alternative could be to add syslog capabilities to all the bb_err_msg_* functions or at least to the underlying
common functions,
set int bb_facility at app start
and change bb_logmode as needed while the app is running,
OTOH we need to create some bb_msg (or maybe use bb_printf)
to do the LOG_INFO + print to stdout stuff 
 
Tito
> vda
> 



More information about the busybox mailing list