When running server, server logs save to wrong files.
Contenf of fml-junk-earlystartup.log should be in the fml-server-[1-3].log.
In the version 1.10.2 is this logging ok.
Maybe some problem inside log4j2_server.xml
I see only ignoreExceptions="true" added to 1.12.2 log4j2_server.xml when compare with 1.10.2 version.
I can second this. All the good stuff is in "junk", the normal files only have fml lifecycle and coremod messages.
I've tried quite a few things to try and get it logging to the right place, but log4j's overenginering has made my attempts fail. If anyone else wants to try they are more then welcome to.
According to my investigation this is fallout from a failed attempt to separate single player logging into the client and server specific files. If a thread is spawned without setting its "effective side" association properly, the "junk-earlystartup" log file will be used. Log4J keeps a threadlocal map with a variable that's supposed to be set to the side, which doesn't happen reliably. For universal threads (shared thread pools etc.) it's practically impossible to set due to ambiguity. It's also redundant with the thread name being logged with every message.
Considering this never worked properly and the usefulness is questionable, I suggest to remove the feature. It'd be better to have 2 sets of log files: latest and debug. latest captures INFO and higher for MC+mods, debug everything.
The status quo is that sp client, sp server and mp client log partially to fml-client-latest.log and another part to latest.log. For the dedicated server it's fml-server-latest.log and latest.log, also not overlapping in any reasonable way. The obvious problem is that you currently always have to check both files.
I have something like this in mind (with color code stripping added):
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="warn" packages="com.mojang.util">
<Appenders>
<Console name="SysOut" target="SYSTEM_OUT">
<PatternLayout pattern="[%d{HH:mm:ss}] [%t/%level] [%logger]: %msg%n"/>
</Console>
<Queue name="ServerGuiConsole">
<PatternLayout pattern="[%d{HH:mm:ss}] [%t/%level] [%logger]: %msg%n"/>
</Queue>
<RollingRandomAccessFile name="File" fileName="logs/latest.log" filePattern="logs/%d{yyyy-MM-dd}-%i.log.gz">
<PatternLayout pattern="[%d{HH:mm:ss}] [%t/%level] [%logger]: %msg%n"/>
<Policies>
<TimeBasedTriggeringPolicy/>
<OnStartupTriggeringPolicy/>
</Policies>
</RollingRandomAccessFile>
<RollingRandomAccessFile name="DebugFile" fileName="logs/debug.log" filePattern="logs/debug-%i.log.gz">
<PatternLayout pattern="[%d{HH:mm:ss}] [%t/%level] [%logger]: %msg%n"/>
<Policies>
<OnStartupTriggeringPolicy/>
<SizeBasedTriggeringPolicy size="200MB"/>
</Policies>
<DefaultRolloverStrategy max="5" fileIndex="min"/>
</RollingRandomAccessFile>
</Appenders>
<Loggers>
<Root level="all">
<filters>
<MarkerFilter marker="NETWORK_PACKETS" onMatch="DENY" onMismatch="NEUTRAL"/>
</filters>
<AppenderRef ref="SysOut" level="info"/>
<AppenderRef ref="File" level="info"/>
<AppenderRef ref="ServerGuiConsole" level="info"/>
<AppenderRef ref="DebugFile"/>
</Root>
</Loggers>
</Configuration>
The latest.log is for everything the user should read, debug.log only for investigating a concrete problem. debug.log doesn't contain the date in the file name, rolling overwrites don't work properly otherwise. Rolling also uses the more common file (=current/latest) -> file-1 -> file-2 .> ... -> file-5 (=oldest) scheme that everything else uses instead of fml's reversed file (=current/latest) -> file-3 -> file-2 -> file-1 (=oldest) scheme. Compressing and size-based rollover triggers for the debug log should help with log spam filling disk space in pathological cases.
Thanks!
I'm currently working on fixing this based on what Player wrote here and with help from @pau101.
Looks like this patch broke server text console, I see no ">" at begin of line, no text when type to console etc.
Previous forge build 2628 works fine.
Most helpful comment
According to my investigation this is fallout from a failed attempt to separate single player logging into the client and server specific files. If a thread is spawned without setting its "effective side" association properly, the "junk-earlystartup" log file will be used. Log4J keeps a threadlocal map with a variable that's supposed to be set to the side, which doesn't happen reliably. For universal threads (shared thread pools etc.) it's practically impossible to set due to ambiguity. It's also redundant with the thread name being logged with every message.
Considering this never worked properly and the usefulness is questionable, I suggest to remove the feature. It'd be better to have 2 sets of log files: latest and debug. latest captures INFO and higher for MC+mods, debug everything.
The status quo is that sp client, sp server and mp client log partially to fml-client-latest.log and another part to latest.log. For the dedicated server it's fml-server-latest.log and latest.log, also not overlapping in any reasonable way. The obvious problem is that you currently always have to check both files.
I have something like this in mind (with color code stripping added):
The latest.log is for everything the user should read, debug.log only for investigating a concrete problem. debug.log doesn't contain the date in the file name, rolling overwrites don't work properly otherwise. Rolling also uses the more common file (=current/latest) -> file-1 -> file-2 .> ... -> file-5 (=oldest) scheme that everything else uses instead of fml's reversed file (=current/latest) -> file-3 -> file-2 -> file-1 (=oldest) scheme. Compressing and size-based rollover triggers for the debug log should help with log spam filling disk space in pathological cases.