Some tests report "FAIL" though the functionality is available

On the config test page, some functions are reported as 'FAIL' though they are available and working fine. Examples are (in my case) the PHP CLI, TTF, swisscenter ini ('not found'), internet radio parser (see* 59). In case of the parsers I checked a bit deeper (since I wrote them): Tests return TRUE, so they should be reported OK on this page.

Leave a comment

on 2011-03-30 10:40 *

By Anonymous

Could you post the part of the support.log that lists the state of the checks (at level 8)? I'll take a look and see what is going on.

on 2011-03-30 10:40 *

By izzy

You've read my mind, huh? I just added some logging to the tests (in base/install_checks, at the end of function get_check_results, I added

foreach ($results as $var=>$val)
{
if ($val !== FALSE)
send_to_log(8, $var.': Check passed');
else
send_to_log(3, $var.': Check FAILED');
}

(will commit these changes soon). Results from Logfile:

[2007.05.22 11:20:59] PHP version: Check passed
[2007.05.22 11:20:59] PHP required mods: Check passed
[2007.05.22 11:20:59] PHP suggested mods: Check passed
[2007.05.22 11:20:59] PHP ini file: Check passed
[2007.05.22 11:20:59] PHP cli: Check passed
[2007.05.22 11:20:59] PHP fonts: Check passed
[2007.05.22 11:20:59] MYSQL version: Check passed
[2007.05.22 11:20:59] MYSQL connect: Check passed
[2007.05.22 11:20:59] MYSQL database: Check passed
[2007.05.22 11:20:59] SWISS ini file: Check passed
[2007.05.22 11:20:59] SWISS write log: Check passed
[2007.05.22 11:20:59] SWISS write root: Check FAILED
[2007.05.22 11:20:59] SWISS root install: Check passed
[2007.05.22 11:20:59] SWISS media locs: Check passed
[2007.05.22 11:20:59] SERVER scheduler: Check passed
[2007.05.22 11:20:59] MUSICIP api: Check FAILED
[2007.05.22 11:20:59] MUSICIP mixable: Check FAILED
[2007.05.22 11:20:59] ShoutCast parser: Check passed
[2007.05.22 11:20:59] LiveRadio parser: Check passed

The page reports instead:

Cron failed (yepp, true)
PHP OK
php.ini OK
PHP modules OK, OK
PHP CLI not found (???)
TTF not found (???)
webserver root (yepp, I protected some dirs)
swisscenter.ini not found (!!!)
logfile not writeable (ahem - how could I copy'n'paste above lines if they were not written?)
MusicIP not found (yepp, not installed)
Shoutcast failed (no, it didn't!)
LiveRadio failed (didn't either)

If needed, I can add a few screenshots (does not fit in one).

on 2011-03-30 10:40 *

By Anonymous

Most of the tests already write to the log when they fail. It's probably best to keep it that way because they write more detailed information (usually at log level 8) which helps with debugging.

A couple of the tests don't have any logging though, I should probably create a ticket to do this so that I don't forget!

PHP CLI not found (???)

This will be reported if the 'which' command reports that it can't be found. Maybe the user that the webserver is running at does not have the PHP binary in it's path?

THe other tests - do they say above them that they failed 'in the background'? That often happens if the PHP cli cannot be found.

BTW - I get an error that shoutcast failed (the log reports it returned an empty list). But live-radio works fine!

on 2011-03-30 10:40 *

By izzy

Of course I kept the other logging inside. What I added was just a part to see all results together instead of needing to search the log for it.

Concerning PHP CLI: If it is not found (and yes, it is in the path of every user), how comes that the media search in the background works fine? If the log file is not writable, how comes that SC is writing into it? If the swisscenter.ini is not found, how comes that it is being used (and even written into)? And, as you can see from my previous post: The PHP CLI etc. is found (the check returns TRUE), as reported by the log:

[2007.05.22 11:20:56] - PHP CLI location : /usr/bin/php

Only the web page says something else. And that's what I meant when opening this ticket: The results shown on the website do not correspond to the results returned by the check functions. No idea why.

As for Shoutcast: I had this once, too - simply reload, and it should look fine again. Must be some problems on the Shoutcast website. If you had logging at level 8 or 9, you can check the log for all 'IRadio:' statements to see more details (or look for 'ShoutCast parser' to see what the check really returned).

All the checks seem to be non-deterministic: One time it says 'failed in the background', next time it simply 'failed' (w/o background). I guess it would help to add some more detailed logging to the test_summary (and, maybe, also to the test_results) class to see what is going on there?

on 2011-03-30 10:40 *

By Anonymous

Oh yes, Sorry! I should have read your original comments more slowly ;)

I'll take a look at the tests page and try to find out why it's displaying the wrong results.

on 2011-03-30 10:40 *

By Anonymous

To confuse you a little bit more: I added some more debugging to the very end of config_checks.php - immediately before the output is created.

Display test results

on 2011-03-30 10:40 *

By Anonymous

Not really strange - it's just that my code is crap ;)

I think I was having a bad day when I wrote that bit of code, because it's really badly done. I haven't rewritten it yet because I'm changing the background tasks to use 'wget ' instead of 'php_cli ' (even on windows - you'll notice that there's a 'wget' command for windows included in the ext directory).

Once I've done that, I'll rewrite the tests because it doesn't need to run them twice (once in the current environment and once via the CLI) because the both foreground and background scripts will be using the same PHP interpreter.

on 2011-03-30 10:40 *

By izzy

I just print_r()ed the entire class now to see what's going on. What I see is that the the results in the sections blocks do not correspond to those in the results block. Need to check how the section block is built - but my first idea is: Why not simply use the results array? E.g. I don't see any reason to shock the user with error results concerning CLI problems with the IRadio parser, since that is never used with the CLI. I understand that you don't want to make too much changes to that stuff anymore - but maybe add another parameter to the add_tests() method whether CLI should be checked or not? You could even let it default to TRUE, and we then change the calls for those functionalities not depending on any command line stuff. Moreover, if we are going to deprecate CLI in favour of wget, CLI would not be used at all anymore (and change the default to FALSE plus remove the unnecessary code).

on 2011-03-30 10:40 *

By izzy

P.S.: About the 'bad day'. Was it the same day you wrote the translations in the EXIF tables? 8-°

on 2011-03-30 10:40 *

By izzy

I just modified the test_summary::add_test() method to accept an additional optional parameter (defaulting to TRUE) whether CLI tests should be evaluated. Then I set that to FALSE for some tests (like the IRadio stuff). Et voila - some more green lights, so this work-around does the job - see revision:720.

Robert: Maybe you want to check which checks can be marked no-CLI, too?

As for Shoutcast: I just noticed they sometimes claim to have no stations listed for the query. But after a simple reload, they find plenty of them. Guess they don't like the limitation to max 2 results I set and feel faked, since the reloaded page returns 20 stations. For now, I just added a note to the description ('please reload' - see revision:722). I will play with this a little bit more to make the test more reliable (but maybe a bit slower => limit 10).

on 2011-03-30 10:40 *

By izzy

Shoutcast now also should report success revision:723 - we simply retry up to 2 times if no stations returned. Now there are only a few items left that report incorrect results...

on 2011-03-30 10:40 *

By izzy

Status changed from New to closed

Oy shit! The solution is that easy... revision:724

on 2011-04-01 12:37 *

By Pernod

Component changed from None to Configuration Pages

Updating tickets (#1, #21, #22, #44, #55, #70, #71, #82, #96, #102, #103, #104)

on 2011-04-01 12:50 *

By Pernod

Priority changed from Normal (3) to High (2)

Updating tickets (#64, #70, #83, #88, #90, #91, #96, #97, #98, #99, #100, #101)

on 2011-04-22 19:35 *

By Pernod

Status changed from Closed to Fixed

Updating tickets (#63, #65, #75, #84, #87, #89, #93, #185, #10, #57, #64, #69, #70, #74, #79, #80, #82, #83, #85, #86, #88, #90, #91, #96, #97, #98, #99, #100, #101, #104, #105, #109, #115, #116, #117, #120, #126, #128, #130, #131, #133, #135, #153, #163, #169, #171, #173, #179, #180, #181, #184, #187, #188, #194, #195, #198, #203, #205, #218, #220, #226, #231, #236, #239, #240, #242, #247, #252, #5, #6, #11, #20, #25, #26, #27, #29, #30, #38, #40, #42, #43, #44, #46, #49, #50, #51, #52, #53, #55, #58, #59, #60, #61, #71, #92, #102, #103, #106, #107, #108, #112, #113, #114, #118, #119, #121, #129, #137, #140, #141, #144, #145, #146, #147, #149, #150, #151, #152, #154, #156, #157, #158, #160, #161, #162, #165, #167, #168, #172, #176, #182, #183, #191, #192, #193, #196, #197, #204, #206, #210, #215, #217, #222, #228, #230, #232, #234, #235, #237, #243, #249, #1, #4, #9, #12, #13, #16, #62, #78, #164, #166, #189, #190, #199, #200, #208, #209, #211, #212, #19, #47, #48)

Drop the files anywhere in this page to upload them as attachments.

Add a Relation

Related Tickets

Add people from your team or external to follow ticket activity

izzy

Attachments

Related Tickets

Followers

Some tests report "FAIL" though the functionality is available

Related Tickets

Add people from your team or external to follow ticket activity

Followers will receive email updates about new ticket activity or emails sent to swiss+70@tickets.assembla.com

Attachments

Related Tickets

Followers

Some tests report "FAIL" though the functionality is available

Granting access, please wait...

Related Tickets

Add people from your team or external to follow ticket activity

Followers will receive email updates about new ticket activity or emails sent to swiss+70@tickets.assembla.com