On Fri, 13 May 2016, Helmut Schaa wrote:
On Fri, May 13, 2016 at 12:03 PM, Bastian Bittorf
<bitt...@bluebottle.com> wrote:
* Conor O'Gorman <i...@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.@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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
