Ubuntu
ampache package

Fix for "Unable to write to log"

Asked by Jim Patterson

I've installed Ampache from the Ubuntu Maverick repository. It has a problem, though. When I visit my "ampache" web site, hosted in Apache 2.2 (also from the repository), each page is plastered with messages like:

    Unable to write to log (/var/log/ampache/ampache.20110219.log) Please check your log_path variable in ampache.cfg.php

My web site is not public, but you can see identical behaviour on this site, which I found through Google:

http://spacemachines.net/ampache/localplay.php?action=show_playlist

** Warning ** you're likely violating someone's intellectual property rights if you actually try to play a song from this site (I haven't).

The underlying problem is that the log file is created each day by user/group root/root, but Apache of course runs as user/group www-data/www-data. My guess as to why this happens is because ampache is set up with a cron job as well, and it's creating the log file first (as it is a php script that pulls in the same Ampache configuration script).

How do people deal with this? Shouldn't the default install avoid this kind of problem?

Thanks.

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu ampache Edit question
Assignee:
No assignee Edit question
Solved by:
Jim Patterson
Solved:
Last query:
Last reply:
Revision history for this message
actionparsnip (andrew-woodhead666) said : 		#1

I suggest you log a bug

Revision history for this message
Charlie_Smotherman (cjsmo) said : 		#2

Jim,

Which version of ampache are you using? To help diagnose your problem would you please post the output of each of these commands:

dpkg -s ampache

ls -l /var/log

ls -l /var/log/ampache

and please post a copy of your ampache.cfg.php.

Please feel free to open a bug, email me privately or we can work through your problem here

cjsmo at ubuntu dot com

Charlie Smotherman
Debian Contributor
Ubuntu Developer

Revision history for this message
Jim Patterson (jimp-launchpad-rs9z) said : 		#3

I'm running the current version in the Maverick repository, Version: 3.5.4-7ubuntu1.

Here's a bit of the log directories:

drwxrwxr-x 2 www-data www-data 12288 2011-02-20 11:37 /var/log/ampache
-rw-r--r-- 1 root root 6537 2011-02-15 22:06 ampache.20110215.log
-rw-r--r-- 1 root root 582053 2011-02-15 22:06 ampache-catalog.20110215.log

To keep things simple, here's the diff between my config and the distributed one. As you can see, the key difference is that I've enabled logging. I think that might explain why I'm seeing this and many others aren't.

jim@fuzzy:$ diff ampache.cfg.php.dist ampache.cfg.php
23c23
< ;web_path = ""
---
> web_path = "/ampache"
 31c31
< database_hostname = localhost
---
> database_hostname = "localhost"
 35c35
< database_name = ampache
---
> database_name = "ampache"
 39c39
< database_username = username
---
> database_username = "ampache"
 45c45
< database_password = password
---
> database_password = "xxxxxxxx"
 337c337
< ;debug = "false"
---
> debug = "true"
 357c357
< ;log_path = "/var/log/ampache"
---
> log_path = "/var/log/ampache"
 566a567
>

The trigger for this seems to be that a) logging is enabled and b) the daily catalog update job kicks in on a new date (hence a new log file), without any intervening web site activity that might pre-create the log. In those circumstances, a new log file gets created as root/root, which causes subsequent web site requests to encounter these logging failures.

I've tried out a simple solution on my system, which is to update /etc/cron.daily/ampache to run this command:

sudo -u www-data php /usr/share/ampache/www/bin/catalog_update.inc -a -c

(I've added "sudo -u www-data", so the command runs as www-data instead of as root, and consequently the log file gets created as this user also).

This could be generalized somewhat. It's possible, if the server has a customized Apache installation, that there is no www-data user in which case the sudo call will fail. Also I suspect it won't work for many lighttpd installations since they seem to prefer lighttpd as the non-root user for the web server.

This variation is a bit more general but still assumes the location of the log directory, and that it's owned by the web server user (which seems reasonable as it needs to be able to write there):

logowner=$(ls -dl /var/log/ampache | sed 's/^d......... [0-9]\+ \([^ ]\+\) .*/\1/')
sudo -u ${logowner} php /usr/share/ampache/www/bin/catalog_update.inc -a -c

This works for me, but might be making too many assumptions to form a robust solution. Something inside the catalog_update.inc script itself would be more flexible (since it would have access to configuration values like 'log_path'), but it would have to be platform-aware (i.e. play nicely with Windows as well).

I think I've answered my question, but I'm going to open up a bug on this as well since the setup should not require this level of tinkering, in my opinion.