rundown of log component by sineemore

[sineemore]

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 my logger 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:

• initialize logger in Lua part and make it explicit
• allow to store logs in specified directory
• optional log rotate
• allow logging to specified file handle (stdout, stderr, custom file handle) or file path
• optional date format
• NO_COLOR
• maybe syslog

[sineemore]

@mitchtbaum, @dariusc93

Currently with every invocation of console application the folder ./log is created in current working directory.

[naturallymitchell]

yea. I don't like it either

[naturallymitchell]

let's start with turning off writing log files by default

[naturallymitchell]

b836ce9

---

initialize logger in Lua part

this is indeed mostly about torchbear-scripts/log (good name?), ie jazzdotdev/log#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

#242
#243

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

[sineemore]

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

• svlogs from runit init system
• rotatelogs from Apache

Also see this article, that describes runit approach at logging.

[naturallymitchell]

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

[sineemore]

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.

[naturallymitchell]

ok, pointing it is good, but making an issue for it is better

structured text > unstructured text