Adds set_level methods to Root and Config objects. This provides the ability to modify the logging level of Root even after Root and Config have been built.

We are using this modification to change the logging level of a Config that is loaded from a .yaml file based on a verbosity flag that is passed in on the command line.

Signed-off-by: Logan Seeley [email protected]

Add {i} and {tid} to allow logging in particular the Linux thread ID as returned by gettid(). This is very useful for system-wide debugging und monitoring with consistent thread/task IDs.

Fixes: #231

One of the main features of a logging framework like log4j 2 is it's separation of concerns:

A developer using log4j may (and should not) bother, ever, with where the logs are, in what format it is, and how to initialize logging.

In principle, people using the application (operators) should be able to choose where the logs will go, and which messages will be shown, where.

Also, operators shouldn't need to "learn" how to configure logs for application A , B , C . There should be a common standard among them.

To force the task of choosing where logs will go to the developer is a hazardous antipattern that have caused a lot of issues on my professional experience with java, unless you develop code utterly alone and don't use third party modules at all:

• Developer of module A decides that he wants to configure logs to send to the file Y, at debug level, not rolling,ever. With dates in format YYYY-MM-DD HH:mm:ss, and a message like "ERROR 2020-11-10 10:00:00 [[[ SOME ISSUE HAPPENED ]]]"

• Developer of module B decides that he wants to configure logs to send files only to the console, at error level. showing messages like ---SOME ISSUE HAPPENED --- ERROR 10-11-2020 14:00:00 <<yep, different timezone

This will make, from the standpoint of an operator, for logs to behave erratically, some messages going some to Y, other to console, with different formats, and impossible for the operator to make head of tail of the mess the logs are.

So when an operator is diagnosing issues, they simply can't know where the evidences are in a consistent manner.

The pattern used in log4j2 for java is something like this:

package x;

public class Y {

	// The LogManager.getLogger() is "miraculous": it deducts that the logger name is "x.Y" (the full qualified class name)
	// and it sees that if the logging system is not initialized yet, it does initialize it looking for all configuration options at some standard
	// location (usually a log4j2.xml placed somewhere in the classpath, but it can be defined by an environment variable or an initialization
	// option from the command line)
	Logger otherLog = LogManager.getLogger(); 

	public void someMethod() {

		// otherLog == log
		Logger log = LogManager.getLogger(); 

		// in java : log2 == log : they refer to the same object. Sharing the same features.
		Logger log2 = LogManager.getLogger();

		// same here: log3 == log : calling getLogger("x.Y") will use the same logger as the others, because the qualified name is the same.
		Logger log3 = LogManager.getLogger("x.Y");

		// all this messages will be sent to the exact same locations, with whatever set format, because all these loggers are the same.
		log.info("test"); 
		otherLog.info("test");
		log2.info("test");
		log3.info("test");
	}
}

There is a need when you have some thing to log which should be keep for some days, but you can not estimate the size it will be (for example user online duration). If you use the size roller, the size may be small and log will be removed. A time roller would be nice to handle this thing.

I have a cron job that zips up all my log files periodically (several programs with both text and binary logs). That moves the entire contents of the log directory, zips them up, then deletes them. Sadly log4rs does not cope with having an open file deleted, and that's the end of that, no more logging. Note that creating a new file with the same name does not fix the problem - log4rs has already given up.

Having written a custom binary log format in C++ for this, I have been through the process myself. When the open file is deleted you have an invalid handle, but you must close that handle. Otherwise you still have an active-but-invalid handle (it will leak!). Then obviously just open a new file and log away.

I believe any test app will demonstrate this problem if you remove the log file while it's being used.

Hello there!

I have realised log4rs does not provide terminal coloration by default. Would you be interested in the feature?

For comparison, loggers such as log4js and winston provides terminal coloration by default.

If you like the idea but don't have the time for it, I would gladly work on it. :)

The use-case is when you only want console output when running a program in console.

resolves #210

Also remove someones .DS_Store file which was probably a mistake.

Currently the log file path from the config file seems to be relative to the current directory. It would be great to have an option (or something like a $EXE_PATH variable to use in the path string) to make this relative to the executable instead.

#167 added a color for trace, but didn't add a match arm to reset the style. This results in all text after a highlighted trace being black. Also of note is that in a dark terminal, the trace highlight is unreadable. I would suggest putting no coloring on it at all if it's going to be black or white.

Hi, after commit 0d0a6dd88047337a9b33292c24addfabac5352d5, there are some build errors on android platform. errors:

   Compiling palaver v0.2.8
error[E0432]: unresolved import `nix::sys::memfd`
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/palaver-0.2.8/src/file.rs:185:8
    |
185 |             use nix::sys::memfd;
    |                 ^^^^^^^^^^^^^^^ no `memfd` in `sys`

error[E0425]: cannot find function `shm_open` in module `mman`
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/palaver-0.2.8/src/file.rs:213:9
    |
213 |         mman::shm_open(
    |               ^^^^^^^^ not found in `mman`

error[E0425]: cannot find function `shm_unlink` in module `mman`
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/palaver-0.2.8/src/file.rs:226:10
    |
226 |             mman::shm_unlink(name).unwrap();
    |                   ^^^^^^^^^^ not found in `mman`

Some errors have detailed explanations: E0425, E0432.
For more information about an error, try `rustc --explain E0425`.
error: could not compile `palaver` due to 3 previous errors

and

   Compiling procinfo v0.4.2
error[E0308]: mismatched types
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/procinfo-0.4.2/src/pid/status.rs:189:1
    |
189 | named!(parse_umask<mode_t>,     delimited!(tag!("Umask:\t"),     parse_u32_octal,    line_ending));
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u16`, found `u32`
    |
    = note: this error originates in the macro `delimited` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0308`.
error: could not compile `procinfo` due to previous error

I was checking a binary with cargo bloat and to my surprise I noticed that log4rs pulled in regex which turned out to be 4x as large as log4rs itself. So I was curious what log4rs is using regex for. I could only find one line with a reg exp matcher that's not even that complex.

$ grep -rni regex .
./Cargo.toml:21:file_appender = ["parking_lot", "simple_writer", "pattern_encoder", "regex"]
./Cargo.toml:22:rolling_file_appender = ["parking_lot", "simple_writer", "pattern_encoder", "regex"]
./Cargo.toml:70:regex = { version = "1", optional = true }
./src/append/mod.rs:29:        let matcher = regex::Regex::new(r#"\$ENV\{([\w][\w|\d|\.|_]*)\}"#).unwrap();

So I'm wondering if you have more plans for regex crate or if you would be willing to replace this one use with a handwritten scanner?

I add the trigger kind "time" in rolling_file. It can be set with limit like 5second, 10minute, 1day, 3weeks...It may be able to solve the Issue #235. I referred to #139 and thank for @SSebo

Please pardon my ignorance, I've been looking around but haven't been able to find anywhere that lists what is expected to be in a config file to load the configuration. I've found a few example but nothing that explains what all the options are. Does this exist and I just missed it? In the documentation it says, "...The file module documentation covers the exact configuration syntax, but an example in the YAML format is provided below...". I've tried looking but I haven't been able to find it. Would appreciate if someone can point me in the right direction.

I have a Date based trigger, so when the date changes it will return true and the logs are rotated. However due to the fact that the rolling file appender writes to the log first, and then check the policy, the first log line each day is written in the old log, before it is rotated.

I think it would be bettter, if the policy was checked at the top of the append function, before the log is written.

Left truncation is the default in the inspiration for this crate (Log4j). It usually produces more relevant results, e.g. for filenames, logger names, etc.

Both styles of truncation should be supported, with right truncation (current implementation) as the default for backward compatibility.

Log4j uses a minus sign on the length (negative length) to flip the truncation. So it might look like this for log4rs: {f:>-15.15} (left truncate or left pad the filename field to exactly 15 chars)