logging.json path not utilized?

[pashdown]

The documentation states that on systems that have logging.default.json and logging.json, the latter overrides the former.  However my logging.json has ""path": "%JELLYFIN_LOG_DIR%//jellyfin.log"" and what is actually created are files with the name jellyfinYYYYMMDD.log, which is fine, execept that I need a plain jellyfin.log to work with fail2ban.  How can I get the settings in logging.json to be respected?

[TheDreadPirate]

I was never able to figure that out. Instead of fighting with logging.json I opted to just symlink log_YYYYMMDD.log to jellyfin.log and at midnight a cron recreates the jellyfin.log symlink for the newly created log. fail2ban complains a bit about there being logs it hasn't seen during the symlink transition, but it still reads them in and follows the new symlink.

The cronjob calls a script with the following contents.

Code:

#!/bin/bash

DATE=$(date +'%Y%m%d')

rm /docker/containers/jellyfin-prod-data/config/log/jellyfin.log
ln -s log_${DATE}.log /docker/containers/jellyfin-prod-data/config/log/jellyfin.log

The script is located in /usr/sbin and is called as follows from root's crontab.

Code:

# m h  dom mon dow   command
1 0 * * * rotateJellyfinLog

[pashdown]

That's what I figured I was going to need to do. BTW, adding a "fail2ban-client reload (jail name)" after you make your symlink will probably stop fail2ban from complaining.

[TheDreadPirate]

Code:

2025-03-30 00:02:01,538 fail2ban.filter         [1841]: WARNING [jellyfin] Detected a log entry 2m 1s before the current time in operation mode. This looks like a latency problem. Treating such entries as if they just happened.

The log message indicates that it is reading in the logs prior to the symlink change. So I'm not going to bother it.