[LEDE-DEV] [PATCH 2/2] [ubox] logd: add ubus reload method

David Lang david at lang.hm
Fri May 13 10:55:04 PDT 2016


On Fri, 13 May 2016, Helmut Schaa wrote:

> On Fri, May 13, 2016 at 12:03 PM, Bastian Bittorf
> <bittorf at bluebottle.com> wrote:
>> * Conor O'Gorman <i at conorogorman.net> [13.05.2016 11:52]:
>>> On 13/05/16 07:23, Alexandru Ardelean wrote:
>>>> Short version is: we have a configuration management system on top of
>>>> OpenWrt ; system boots with default settings (on every boot), and
>>>> config management applies config changes (whether it's right after
>>>> boot, or during system's normal operation).
>>>> Maybe other people do something similar.
>>> Not many. Most people store the config, which is the current model.
>>> It has benefits.
>>
>> We also have an approach like Alexandru, but i dont see
>> the problem: logd starts at START='12'. Our config-thingy
>> fires at START=01 and uci-sets all the stuffs. So we can still
>> "rotate the knobs" e.g. uci set system. at system[0].log_size=64
>
> I was thinking of a different use-case:
> Increasing the buffer size on the fly comes in handy during a debug session
> where you'd like to not interrupt logging (and thus potentially lose some parts
> of the syslog when restarting logd).
>
> Independent of how the implementation looks like I think the functionality
> would be quite useful.

I don't think it's very valuable. If you are debugging, you really don't want to 
be tweaking anything in the middle of trying to capture data. you want to set 
everything up and let it run, then analyze the data.

I don't see that changing the log size in the middle of a capture run is a good 
idea, let alone one that is common enough to have to introduce uci specific 
knowledge into the logd daemon.

You are better off sending to a remote logserver anyway.

David Lang



More information about the Lede-dev mailing list