[RESEND PATCH] add bb_info_msg was Re: Applets send errors to syslog during normal, successful operation
Tito
farmatito at tiscali.it
Wed Feb 28 20:13:12 UTC 2018
On 28/02/2018 18:27, Deweloper wrote:
> On Wed, 28 Feb 2018 14:03:46 +0100
> Tito <farmatito at tiscali.it> wrote:
>
>> Hi,
>>
>> forgot to add the [PATCH] tag so I resend it.
>>
>> Ciao,
>> Tito
>>
>> On 04/02/2018 19:53, Denys Vlasenko wrote:
>>> On Thu, Nov 30, 2017 at 9:51 PM, Tito <farmatito at tiscali.it> wrote:
>>>> On 11/30/2017 08:26 PM, Deweloper wrote:
>>>>> Many applets are daemons (or can be run as daemons) and send messages to
>>>>> syslog. The problem is that the messages don't have accurate, individually
>>>>> assigned severity; they are all LOG_ERR. Effectively, system
>>>>> administrator sees a lot of ERRORs in the log even when everything goes
>>>>> well. It seems that libbb provides only bb_error_msg() as a convenient
>>>>> way to print a message (including sending it to syslog), while a more
>>>>> generic function taking severity as well would be needed instead. grep -r
>>>>> 'syslog(' shows that only some loginutils call syslog() directly. In
>>>>> other places bb_error_msg() is used even for informational or verbose
>>>>> debugging messages. Just have a look at output of grep -r 'bb_error_msg('
>>>>>
>>>>> Do you have an idea how to clean this up? Shouldn't these messages be
>>>>> sent to a new function, e.g. bb_msg(), which would additionally take
>>>>> "severity" argument?
>>>
>>> The "severity" arg usually ends up being a PITA.
>>> For example, it's rather unreadable.
>>> Then, it tends to proliferate: after you have errors/not-errors,
>>> then someone wants critical/errors/not-errors/debug - which adds
>>> another dimension to coding every error message: "what severity is it?!"
>>>
>
> Sorry, but this is how syslog() API is designed.
>
>>>
>>>> 4) create a function that changes syslog_level to LOG_INFO, add it to
>>>> libbb, and then change the code of the applets accordingly, for example:
>>>>
>>>> void FAST_FUNC bb_info_msg(const char *s, ...)
>>>> {
>>>> va_list p;
>>>> #if ENABLE_FEATURE_SYSLOG
>>>> smallint syslog_level_old = syslog_level;
>>>> syslog_level = LOG_INFO;
>>>> #endif
>>>> va_start(p, s);
>>>> bb_verror_msg(s, p, NULL);
>>>> #if ENABLE_FEATURE_SYSLOG
>>>> syslog_level = syslog_level_old;
>>>> #endif
>>>> va_end(p);
>>>> }
>>>
>>> I like this. Feel free to send patches doing this.
>>>
>
> As of busybox 1.28.0 the exported global variable syslog_level seems to be used only in one place @miscutils/crond.c:
>> syslog_level = LOG_INFO;
>> bb_verror_msg(msg, va, /* strerr: */ NULL);
>> syslog_level = LOG_ERR;
> IMO it would be much better to completely get rid of it and - surprise - use function parameters for passing parameters to functions.
>
Hi,
I think that it is not that practical to add one more parameter to all
bb_error_msg and bb_error_msg_and_die calls because:
1) they are error messaging functions and LOG_ERR is mostly right
2) if ENABLE_FEATURE_SYSLOG is not set they don't do any syslog
messaging at all and the parameter would be superfluous.
3) it will increase space
4) syslog_level allows already to to handle exceptions (set to LOG_INFO
or other LOG_...)
5) bb_info_msg is a commodity function of 4) to better tune
syslog output by using existing machinery of libbb
without "uglyfying" the code with syslog_level = LOG_INFO
and syslog_level = LOG_ERR line pairs and it
is automagically converted to bb_error_msg if
ENABLE_FEATURE_SYSLOG is not set, needs no extra args and
should not increase binary size that much.
Ciao,
Tito
BTW: miscutils/crond.c: seems the perfect place for using bb_info_msg.
More information about the busybox
mailing list