Open sineemore opened 5 years ago
@mitchtbaum, @dariusc93
Currently with every invocation of console application the folder ./log
is created in current working directory.
yea. I don't like it either
let's start with turning off writing log files by default
https://github.com/foundpatterns/torchbear/commit/b836ce9231c1bd2189a1beac59ea12f0e0e25b3b
initialize logger in Lua part
this is indeed mostly about torchbear-scripts/log (good name?), ie https://github.com/torchbear-scripts/log/issues/5
and make it explicit
that log project is part of torchbear-libs, so it's meant to be used by default. for example, gut imports it and lighttouch imports it too.
mp
sync
can be used to resolved dependencies manually. mp install app
fetches apps with their dependencies.
I need to document this.
Currently logs are initialized in src/lib.rs by Rust part before any Lua code is started.
this is only the Rust environment log from the log crate. its bindings are there, but now they're prefixed with underscore, ie _log.debug ()
, to not interfere with log.debug()
.
idk what to do with it so well. if it were up to me, there'd be trace()
for every function with what usually goes into documentation comment blocks, but just as a simple headline, and maybe even a link to that source code line
what else do you think we should do with Rust's log module? (btw, it's not that good, and idk what's going on with "structured logging" effort, or whatnot)
best thing going so far sorta at this level is that we're catching panics and making it easier to make sending the log to us better. see component/panic tag
I guess for the init system you want that scripted. I haven't studied init systems patterns much, so I don't get why this would be good at any level. please explain further what you have in mind
maybe syslog
rust-syslog is built on top of the log crate, so I doubt it'd be worth it to use much. I'd rather build a new system on top of torchbear's functionality
I guess for the init system you want that scripted. I haven't studied init systems patterns much, so I don't get why this would be good at any level. please explain further what you have in mind
Also see this article, that describes runit approach at logging.
you didn't say which log engine to target. I assume both
we need an issue here with model/plan
that lists each thing to do for the internal log
it seems like you might be getting sidetracked from logging and talking about init systems. so does systemfd address anything you have in mind? that's another topic too that we need to discuss
really looking for plans at this point
Nope, we shouldn't target any of those.
They are used simply as in torchbear script.lua arg1 arg2 | logger
pipeline, so they are already supported (cause we output logs to stdout anyway).
One more issue I can think off is undesired colored logs in standard output: by default logs in terminal are colored, we can toggle color support with enviroment variable NO_COLOR. But when I redirect torchbear command to a file (or a subprocess like in pipeline above) the colored logs will make it trough and reside in file.
You can test it with simple init.lua, which will raise a colored error:
#yyy
Run it like this:
$ torchbear init.lua > out.log && less out.log
The out.log will contain the escape sequences. I guess it is wrong behaviour.
ok, pointing it is good, but making an issue for it is better
structured text > unstructured text
Currently logs are initialized in src/lib.rs by Rust part before any Lua code is started. This approach is useful for daemons, but not flexible for interpreter applications.
A bit of background: in my last project I've created a light C init system with supervisor (similar to runit). All daemons started by the init system where configured to print logs to stdout. The init system collected the logs via a custom logger in a fashion of
sshd -e ... | logger -rotate 5m /var/log/sshd
. So the logging was managed by the init system and daemons where only configured to print logs to standard output/error. Also I've disabled (where possible) output of timestamps and configured them in mylogger
program, so I have similar logs date format across all system.My point of view here: even in daemon mode where out of the box proper behavior is a desired thing it is required to have additional options I've described above.
My thoughts on this: