On Sun, Mar 23, 2008 at 06:01:40PM +0000, The Fungi wrote: > I'm running into a similar (potentially related?) issue running > 1.6.1 on sid (checksumming enabled, configured for daemon mode). > Noticed that the daily cronjob was failing, complaining: > > Could not read config file: No such file or directory at > /usr/share/apt-cacher//apt-cacher-lib.pl line 39. > > I think I narrowed it down to invocation of abs_path($configfile) > clearing out the variable the second time around. I modified the > script so that it looks like: > > warn "Configfile is $configfile\n"; > abs_path($configfile); > warn "Configfile is $configfile\n"; > > And get the following output from the cronjob now: > > Configfile is /etc/apt-cacher/apt-cacher.conf > Configfile is /etc/apt-cacher/apt-cacher.conf > Configfile is /etc/apt-cacher/apt-cacher.conf > Use of uninitialized value in concatenation (.) or string at > /usr/share/apt-cacher/apt-cacher-cleanup.pl line 61. > Configfile is > Could not read config file: No such file or directory at > /usr/share/apt-cacher//apt-cacher-lib.pl line 39.
Thanks, this is VERY helpful. I have been completely unable to work out what is going wrong in these related reports. The double invocation is because is apt-cacher-cleanup.pl is invoked as root, it rexecs itself as the correct user. I suspect that the abs_path is failing when running as www-data due to some permissions issue. But, I never really understood why it is there anyway. Seems redundant to me, but it was in the script as I inherited it. I can't see any bad effects of removing it, so will try that. Thanks for pinning this down. Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
