Hi Stan, first: thanks for explaining and filing a bug in the first place. I should have said so in the first place... :-) +anyway:
On Montag, 25. Juni 2012, Stan Hoeppner wrote: > You misread my report, and closed this prematurely. well... I'm not sure about that ;) and more importantly, I still don't see a specific bug I can identify, track and fix. And at least 5 others read this (and actually everybody can reopen bugs. And I'd be happy to reopen "yours", but I don't (yet?) see how.) > Note that I simply > kept my original config files during safe-upgrade. When munin didn't > work, I replaced them withe the new 2.0 files provided by the upgrade > process. Munin still didn't work. I followed the instructions you > linked, including the lighttpd configuration here: > http://munin-monitoring.org/wiki/CgiHowto2 note that lighttpd is not supposed to work out of the box. apache2 is supposed to work. > and it still doesn't work. The cgi and html processes launch but hang. > According to this: > > > The FastCGI processes will log to "/var/log/munin/munin-cgi-graph.log" > and "/var/log/munin/munin-cgi-html.log". > > Note that these run with the web server's permissions, unless specified > otherwise. If the web server does not have write access to the specific > log files (or access to the directory they are in), the cgi processes > will hang, and not produce any output. yes, you will need to fix the perms. > > they should only hang when write access isn't present. But there are > entries in these log files, though it seems they're not complete, so > maybe one process can write them but no all the processes that need to: > > [root@greer]/var/log/munin$ cat munin-cgi-graph.log > 2012/06/25 11:23:34 Opened log file > 2012/06/25 11:23:34 Opened log file > 2012/06/25 11:23:34 Opened log file > 2012/06/25 11:23:35 Opened log file > [root@greer]/var/log/munin$ cat munin-cgi-html.log > 2012/06/25 11:23:32 Opened log file > 2012/06/25 11:23:33 Opened log file > 2012/06/25 11:23:33 Opened log file > 2012/06/25 11:23:33 Opened log file > > If indeed it's a permissions issue, why doesn't the installer script set > the correct permissions on these files automatically like most/all other > packages do? because the package only supports apache2. > When I installed munin 1.4.x I had zero problems getting it working. > Why are so many contortions required to get the 2.0 upgrade working? because graphing used to be done every 5min from cron, now it's done on demand by a cgi script. > The upgrade installer is simply broken. This isn't the Debian Stable I > know and love. backports is not Debian stable. They are supposed to work well, but they are much less tested than Debian stable. > My big complaint is that an 'aptitude safe-upgrade' shouldn't install a > package upgrade that is so completely broken and does not work without > major surgery. The backports repo is supposed to contain stable working > packages backported from testing, or so I thought. And frankly I'm > surprised a safe-upgrade pulls packages from backports. I was under the > impression it only pulls from the stable repo. And, no, I've never > modified any apt preferences or whatever to cause it to pull packages > from backports. I don't even know how this would be done. This is > something that happened automatically. no. I don't know which backports repo you are refering to, but if you simply add the sources mentioned on backports.debian.org to your sources.list of a debian Stable system, I'm quite sure "aptitude safe-upgrade" won't install munin 2.0 from backports unless you have done something. "apt-get dist- upgrade" (and upgrade as well) certainly wouldn't (install any package from backports.org for that matter). for that you either need to explicitly say "apt-get install -t backports munin" or reconfigure apt/aptitude to grab packages from backports by default, which is not sensible. > So what do I do now? Can 2.0 be made to work on my system? sure. easily with apache2 and with some work with lighttpd. > Or is it > simply completely hosed? Should I file a bug report against the upgrade > script? If so, how do I do that? What's the package name for it? aptitude, but see above. > I, the user, did nothing to break my munin. Fault lay with the > developers. An upgrade shouldn't completely totally break a program so > that it simply won't run at all, which is what has happened here. This > is very frustrating to say the least. > > If this is not a bug, and a bug report isn't the proper place to receive > troubleshooting assistance to get this working, where do you recommend I > go for assistance? Please don't say "debian-users". I've been a > subscriber for over 3 years. Munin is never discussed and there's > likely no other munin users there who could help. the only munin bug I see here is "please add support for automatic configuration with lighttpd" and for that I'd prefer a patch or at least help, as I'm not a lighttpd user myself. And for that I'd prefer a new bug to not have this as irrelevant history to a simply request :-) What do you think? cheers, Holger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
