RuneAudio Forum

Hi,

I think it's a good idea to have less logging active by default. It just fills the root file system and stresses cheap SD cards.

1. Disable mpd log file because it's growing very fast:

Code: Select all

[root@runeaudio ~]# ls -lh /var/log/runeaudio/
total 22M
-rw-r--r-- 1 root root 22M Mar  5 05:51 mpd.log
-rw-r--r-- 1 root root 74K Mar  5 04:36 mpdscribble.log
-rw-r--r-- 1 root root  55 Jan  4  2000 rune_SY_wrk.log

2. Disable nginx access log

3. Reduce systemd logging EDIT: already disabled

A nice idea would be to mount /var/log to tmpfs. That way you avoid writing to sd card. The only disadvantage is that all logs are gone after reboot.

I was able to shut off nginx logging by adding "access_log off;" to /etc/nginx/nginx.conf in the "http" section.

I also noticed samba was regularly complaining about printers, so I added "printcap name = /dev/null" to /etc/samba/smb.conf in the "global" section. There were some other samba complaints that I saw on each reboot that I fixed, so here is my complete smb.conf file for reference:

Code: Select all

#======================= Global Settings =======================

[global]

   workgroup = RUNENET
   server string = RuneAudio Player
   dns proxy = no
   log level = 0
   syslog = 0
   security = user
   guest account = root
   map to guest = bad user
   #map untrusted to domain = yes
   load printers = no
   disable spoolss = yes
   printcap name = /dev/null
   domain master = no
   local master = no
   preferred master = no
   unix extensions = yes

#======================= Share Definitions =======================

   directory mask = 0775
   create mask = 0775

[MPD]
   comment = MPD root (/mnt/MPD)
   path = /mnt/MPD/
   read only = no
   public = yes
   follow symlinks = yes
   wide links = yes
   hide files = /lost+found/

MPD has proven a bit more troublesome to neuter. I can comment out

Code: Select all

log_file       "/var/log/runeaudio/mpd.log"

in /etc/mpd.conf which kills logging, but the UI then complains that manual changes have been made to the file. Checking in the /var/www/mpd-config.php file I see that there is a hash check of the mpd.conf file. I can code around that, but that makes for a rather unclean approach.

Unless I'm mistaken, systemd logging is already disabled. I found

Code: Select all

Storage=none

in /etc/systemd/journald.conf which indicates the process is running, but not logging anything. Poking around in the /var/log/journal folder found a directory named "bef254e7fd904a3faaed5abbedb6262d". Inside that folder were 2 large (3MB) log files with old modification time stamps, so I took a chance. I deleted and re-touched both files, and did a reboot to see if they would grow in size. I'm happy to report that neither did, so I think systemd is already good to go. We're probably safe deleting the entire /var/log/journal folder.

php-fpm is also logging, so find and change the "error_log" line in /etc/php-fpm.conf to be

Code: Select all

error_log = /dev/null

What's left to kill?

NullDev wrote:Unless I'm mistaken, systemd logging is already disabled. I found

Code: Select all

Storage=none

in /etc/systemd/journald.conf which indicates the process is running, but not logging anything. Poking around in the /var/log/journal folder found a directory named "bef254e7fd904a3faaed5abbedb6262d". Inside that folder were 2 large (3MB) log files with old modification time stamps, so I took a chance. I deleted and re-touched both files, and did a reboot to see if they would grow in size. I'm happy to report that neither did, so I think systemd is already good to go. We're probably safe deleting the entire /var/log/journal folder.

Indeed the journalctl command only shows old entries in the log file /var/log/journal folder is not updated.
Also in the Arch wiki I've found this:

In Arch Linux, the directory /var/log/journal/ is a part of the systemd package, and the journal (when Storage= is set to auto in /etc/systemd/journald.conf) will write to /var/log/journal/. If you or some program delete that directory, systemd will not recreate it automatically; however, it will be recreated during the next update of the systemd package. Until then, logs will be written to /run/systemd/journal, and logs will be lost on reboot.

https://wiki.archlinux.org/index.php/systemd#Journal

So without that folder logging will go to a tmpfs. But as you have already mentioned: logging is disabled in /etc/systemd/journald.conf and deleting the folder before creating the image should be fine.

Midnight wrote:So without that folder logging will go to a tmpfs. But as you have already mentioned: logging is disabled in /etc/systemd/journald.conf and deleting the folder before creating the image should be fine.

You are right

Sorry for my mistake.

In the next release all logfiles go to tmpfs. Here is an extract from /etc/fstab

Code: Select all

logs        /var/log                   tmpfs   nodev,nosuid,noatime,mode=1777,size=5M           0  0
rune-logs   /var/log/runeaudio         tmpfs   nodev,nosuid,noatime,mode=1777,size=5M           0  0

Ciao.

Simone

NullDev wrote:MPD has proven a bit more troublesome to neuter. I can comment out

Code: Select all

log_file       "/var/log/runeaudio/mpd.log"

in /etc/mpd.conf which kills logging, but the UI then complains that manual changes have been made to the file. Checking in the /var/www/mpd-config.php file I see that there is a hash check of the mpd.conf file. I can code around that, but that makes for a rather unclean approach.

Hi NullDev,
mpd.conf is generated in one-way from php. So if you directly mod the mpd.conf the application will go into "advanced mode" where you have the possibility to edit the configuration file manually, but you loose the GUI functionality. The idea behind that is if you are an advanced user, you don't need GUI, and probably prefer to edit MPD configuration directly.
This could change in the future, but not now, because we are focused on other aspects of the application.

You can control what php writes on the mpd.conf file by acting on the cfg_mpd SQLite table.

cfg_mpd table structure

Code: Select all

sqlite> .schema cfg_mpd
CREATE TABLE cfg_mpd (
id INTEGER PRIMARY KEY,
section CHAR(20),
param CHAR(20),
value CHAR(100),
description TEXT
, value_player char(200), value_default char(200), example char(200));

Here is the query used in mpd.conf generation: SELECT param,value_player FROM cfg_mpd WHERE value_player!='';

Code: Select all

sqlite> SELECT param,value_player FROM cfg_mpd WHERE value_player!='';
follow_outside_symlinks|yes
follow_inside_symlinks|yes
db_file|/var/lib/mpd/mpd.db
log_file|/var/log/runeaudio/mpd.log
pid_file|/var/run/mpd/pid
music_directory|/mnt/MPD
playlist_directory|/var/lib/mpd/playlists
state_file|/var/lib/mpd/mpdstate
user|mpd
bind_to_address|any
port|6600
log_level|default
zeroconf_enabled|yes
zeroconf_name|runeaudio
audio_output_format|disabled
volume_normalization|no
audio_buffer_size|512
buffer_before_play|0%
filesystem_charset|UTF-8
id3v1_encoding|UTF-8
gapless_mp3_playback|yes
auto_update|no
mixer_type|disabled
group|audio
dsd_usb|yes


this is the php code that generate mpd.conf (you can see the complete function on our GitHub repo)

Code: Select all

function wrk_mpdconf($outpath,$db) {
// extract mpd.conf from SQLite datastore
   $dbh = cfgdb_connect($db);
   $query_cfg = "SELECT param,value_player FROM cfg_mpd WHERE value_player!=''";
   $mpdcfg = sdbquery($query_cfg,$dbh);
   $dbh = null;
...


Code: Select all

// parse DB output
   foreach ($mpdcfg as $cfg) {
...

if you want to exclude log_file parameter from the mpd.conf output, you have to empty value_player and value_default fields for that param (mpd configuration parameter label).
You can do that by executing this from player console:

Code: Select all

sqlite3 /var/www/db/player.db "update cfg_mpd set value_player='', value_default='' where param='log_file';"

then re-generate mpd.conf by making some change via mpd-config page or simply reset mpd to default settings.

I want to take this opportunity to thank you, Midnight, tux, skrodahl and all other people on the forum for your precious hints. With your effort RuneAudio will be even better.

Thanks.

Simone