Frontend Login Woes

[supersport]

We've been using zabbix off and on since 1.0. We've recently decided to expand our use of it, and as such, I've been tasked with getting it installed on some of our servers. The problem we're having is with the frontend. First, the environment:

• OS: Gentoo (fairly up to date)
• Apache: 2.0.59-r5
• Zabbix: 1.4.2
• 5.0.44
• PHP: 5.2.4_pre200708051230-r2
• Extra Wrinkles: The frontend (and server) are running on a linux-vserver guest...I don't think that this is an issue, but I feel it prudent to mention it

Now, for the problem:

When I try to login to the frontend, the browser times out. This is not good, but to make matters worse, the apache process appears to get "hung" and continues to eat up CPU cycles even after the browser times out. That means that for every time I click on "Login", I get another hung apache process. Early on in my testing, I made the terrible mistake of trying several logins in a row...the server nearly fried...the load average was at 67 the last time I was able to check, and after that, it was completely unresponsive (we had to reboot).

Now for some testing/troubleshooting/observations:

• Other web sites on that server seem to be fine, including features such as logging in and sessions
• When trying to add debug statements to the beginning of some of the php files, I don't see any output
• We were just able to reproduce this error on another machine, with nearly the same configuration, but without any virtual servers

I have searched through the forums and wiki, but as yet, I haven't seen anything that may resemble this issue.

Any thoughts or suggestions would be much appreciated

[Niels]

Which browser do you use? Konqueror can't login properly.

[supersport]

Firefox 2.0.0.6

We have another install of Zabbix on a different cluster of servers (slightly different versions of some stuff), and it works just fine.

[Aly]

In my opinion, if hangs Apache and it definitely shouldn't, there are problems in Apache-PHP. There is noway via php-script apache server should hangs

[richlv]

a quick note regarding konq.

during my test sessions (pre-1.4.1), both konq and opera could login nicely on a fresh install, but had a weird problem if the installation was upgraded from 1.1.
so i'd guess it is some problem with zabbix frontend, but i haven't taken much time to investigate as there is a workaround - after logging in, choose 'cancel' in konq (opera either reloaded page or showed blank page - if it reoads stop the process), position the cursor in address bar and resubmit the url.

would be nice to fix this annoyance, but i'm not sure when would i have the time to investigate (and when anybody would have the time to fix it )

[supersport]

Problem Solved

It turns out that the timeout was that zabbix/php seemed to be in an infinite loop, trying to enter a row into the ids table. When I echo-ed out the "error" function from include/config.inc.php, it was showing this (many, many times):

Error in query [select nextid from ids where nodeid=0 and table_name='profiles' and field_name='profileid'] [Table 'zabbix.ids' doesn't exist]
mysql_fetch_array(): supplied argument is not a valid MySQL result resource[/var/www/localhost/zabbix/include/db.inc.php:411]

From there I looked in create/mysql.sql, but did not see the commands to create that table.
I don't have any idea how it gets created normally (as the other setup we have has that table, but the create/mysql.sql file doesn't have it either), but I ran the following sql:

mysql> create table ids (
    -> nodeid int(11) NOT NULL DEFAULT 0,
    -> table_name varchar(64) NOT NULL,
    -> field_name varchar(64) NOT NULL,
    -> nextid bigint(20) unsigned NOT NULL DEFAULT 0,
    -> PRIMARY KEY (nodeid,table_name,field_name));

And now it works like a charm.

Just a follow-on question...was there some step that I missed that should have created that table?

[richlv]

1.4 branch has create/schema/schema.sql, which is creating that table.

1.4.1 and 1.4.2 both have mysql.sql, but that file has 'ids' table creation part.

so, you must be missing that table for some other reason.

also, upgrading for both of these creates that table, and we have the table in the db - but accessing zabbix login with konq still results in those reloads.