I've just noticed that the location for the log file has changed.
It used to be logged to /var/tmp
Now it's logged to ~/.xbmc/temp
My machine has a flash drive for the OS and the home directory is on that. I'd very much prefer that the logging for XBMC went to a more standard location for linux like /var/log/xbmc.
I've already symlinked /var/log (and var/tmp for XBMC) to a "real" HD so I don't burnout the flash drive with the continuous writing that XBMC does with the log set to debug mode.
Now I have to symlink ~/.xbmc/temp. Please, can the logging move to a more standard location.
Oh, and the temp/temp directory seems a bit redundant. Not sure why there needs to be .so files in the temp directory either. Could they go somewhere else
Yes, please move the log files. XBMC just filled up the root partition because I didn't setup the temp directory redirect quickly enough. A 250Mb XBMC log file nicely filled up the free space I had on the 4Gb flash drive for the OS. Many things don't like it when they can't write to disk.
Um, how did you manage a 250MB log file? That's doing rather well.
There was a reason why it was moved, but I'm not sure what that was (the temp directory needed to be moved as we run .so's from there, as you have found).
jmarshall Wrote:Um, how did you manage a 250MB log file? That's doing rather well.
There was a reason why it was moved, but I'm not sure what that was (the temp directory needed to be moved as we run .so's from there, as you have found).
I've got full debugging turned on and just turned on music library scanning on startup. That generates a hefty amount of output. Not all of the library has been scraped so there's all that additional stuff as well.
Might be best to have a temporary directory as well as a logging directory. I don't think logging to a location under the home directory is common practice.
I remember reading a commit comment that executables can't be run from /tmp. Perhaps that's why the .so files have been moved. The log used to be going to /var/tmp though, so not sure why that would have needed to move. Either way, I'd still advocate that logging to /var/log or /var/log/xbmc would be the more correct location.
Hello,
I second the idea to move the log file back to /var/tmp.
Afaik log files in the user directory should be a very rare exception.
But why can't we introduce a option into advancedsettings like <logfileprefix>?
hal2100 Wrote:Hello,
I second the idea to move the log file back to /var/tmp.
Afaik log files in the user directory should be a very rare exception.
But why can't we introduce a option into advancedsettings like <logfileprefix>?
If it has to be moved anyway, I'd prefer it to go into /var/log/xbmc. /var/log is not quite as good if the logged in username is still being used as the filename (I can't tell if that's the case because my HTPC login is xbmc).
Agreed, but this was done because we don't want to spam the /var partition.
IMO we should try to get a consistent log destination on all builds in order to make it easier to request the log on forums/trac.
I will talk to the other linux devs about adding an as.xml value to specify the log folder and moving the log to a more common location like /var/log/xbmc.
vdrfan Wrote:Agreed, but this was done because we don't want to spam the /var partition.
Quote:/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.
Some portions of /var are not shareable between different systems. For instance, /var/log, /var/lock, and /var/run. Other portions may be shared, notably /var/mail, /var/cache/man, /var/cache/fonts, and /var/spool/news.
/var is specified here in order to make it possible to mount /usr read-only. Everything that once went into /usr that is written to during system operation (as opposed to installation and software maintenance) must be in /var.
If /var cannot be made a separate partition, it is often preferable to move /var out of the root partition and into the /usr partition. (This is sometimes done to reduce the size of the root partition or when space runs low in the root partition.) However, /var must not be linked to /usr because this makes separation of /usr and /var more difficult and is likely to create a naming conflict. Instead, link /var to /usr/var.
From
http://linux.tnc.edu.tw/techdoc/linux-books/rute about the standard Linux filesystem
I am not a native speaker of English, but this seems to exactly where we want the log file to be, or am I interpreting the standard wrong?
As well as the problem noted by jmarshall, *nix systems become very unhappy when the volume their /tmp and /var directories reside on run out of space. I'd much rather inconvenience the few than risk instability on all systems.
EDIT: /var/log isn't world writable so that's no option.
I wondered where the hell my log files went lol! ^_^
althekiller Wrote:As well as the problem noted by jmarshall, *nix systems become very unhappy when the volume their /tmp and /var directories reside on run out of space. I'd much rather inconvenience the few than risk instability on all systems.
EDIT: /var/log isn't world writable so that's no option.
Many of the applications I use that perform reasonably intensive logging, log to a child directory in /var/log. For example, Mythfrontend logs to /var/log/mythtv/mythfrontend.log
I've only used linux for 2-3 years now, but based on experience of logging in other applications, logging to /var/log/xbmc seems like the correct place. sudo is already needed for make install, so would it be possible to create /var/log/xbmc and set the appropriate permissions for it as part of the install process?
/home is often moved to a separate partition for more savvy linux users, but this is typically to allow quicker rebuild cycles with a new distro/OS rather than to prevent the OS from being taken down by /home filling up the disk. In many cases /home will be on the same physical disk/partition as the OS (and probably /var and possibly /tmp) so it doesn't matter which directory is filled up. Once the disk is full all directories are affected and bad things will ensue. Logging to /var/log/xbmc at least implies that sort of behaviour.
Filling up the /home directory seems more problematic than filling up /tmp or /var as it's not generally assumed that any process will be rampantly taking up disk space in /home. Finding the file that has nuked your system buried inside a hidden directory in the /home/xbmc directory was unexpected.