Thread: [Nagios-db-devel] Segfaults with the postgres ned
Status: Beta
Brought to you by:
bench23
From: Tim V. <dj...@ro...> - 2005-01-14 13:30:53
|
Hi guys, First a word of thanks for so quickly creating these database plugins for Nagios 2. I'm also converting our monitoring infrastructure from a old netsaint to nagios 2. And for certain things like reports we need the databse integration. So I've been trying to get your module to work. But I can't get it to run. I always get a segfault. I'm currently trying it to work with postgres 7.3.4. I first found out that the querify function was not working. All strings were missing the final '. So I just removed the piece of code that sets them and added them myself to the printf statements. That fixed the first segfault. Then I'm still getting a segfault at the PQclear at the end of the processtatus function. And I'm unable to find out why. The status of the query is ok, no error. Getting a bit frustated about not being able to test and help out with this I've had another idea. Why not change the code/ add a 3 module/... to call external PHP code that does the actual DB work. It is pretty simple to make commands out of PHP code (see pear for example). This would allow at the beginning to test and develop much faster since no recompiles are needed. Just chaning the PHP code is enough. And with PHP you can also very easy do DB abstraction and that kind of stuff. Then later, when the code is stable enough, you can port the PHP code to C to gain performance. So, what do you think ? Is it worth the effort ? Else I look for other people to help my find out why the segfault and maybe help with abstracting the DB code in the UI. Kind regards, Tim -- Tim Verhoeven - dj...@ro... - 0479 / 88 11 83 /* This is total bullshit: */ linux-2.6.6/drivers/video/sis/init301.c |
From: Matthew K. <mk...@ma...> - 2005-01-14 15:21:46
|
> So, what do you think ? Is it worth the effort ? Else I look for other > people to help my find out why the segfault and maybe help with > abstracting the DB code in the UI. I'll be setting up the postgres module this weekend and will let you know how it goes. As for abstracting the db code in the ui, I hope to be finished with that over the weekend. I've done up a simple set of classes with a dependence on PEAR's db to handle the differences between postgres and mysql. It should also make adding another database pretty easy. -- Matthew Kent <mk...@ma...> http://magoazul.com |
From: Ben <be...@si...> - 2005-01-14 17:56:33
|
I'm pretty green when it comes to PHP.... this *will* keep the ability to do persistant connections, right? On Fri, 14 Jan 2005, Matthew Kent wrote: > > So, what do you think ? Is it worth the effort ? Else I look for other > > people to help my find out why the segfault and maybe help with > > abstracting the DB code in the UI. > > I'll be setting up the postgres module this weekend and will let you > know how it goes. > > As for abstracting the db code in the ui, I hope to be finished with > that over the weekend. I've done up a simple set of classes with a > dependence on PEAR's db to handle the differences between postgres and > mysql. It should also make adding another database pretty easy. > -- > Matthew Kent <mk...@ma...> > http://magoazul.com > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Nagios-db-devel mailing list > Nag...@li... > https://lists.sourceforge.net/lists/listinfo/nagios-db-devel > |
From: Matthew K. <mk...@ma...> - 2005-01-14 18:16:18
|
On Fri, 2005-01-14 at 17:56, Ben wrote: > I'm pretty green when it comes to PHP.... this *will* keep the ability to > do persistant connections, right? > It should work as PEAR's db class supports it, but I'll be sure to check in testing. > On Fri, 14 Jan 2005, Matthew Kent wrote: > > > > So, what do you think ? Is it worth the effort ? Else I look for other > > > people to help my find out why the segfault and maybe help with > > > abstracting the DB code in the UI. > > > > I'll be setting up the postgres module this weekend and will let you > > know how it goes. > > > > As for abstracting the db code in the ui, I hope to be finished with > > that over the weekend. I've done up a simple set of classes with a > > dependence on PEAR's db to handle the differences between postgres and > > mysql. It should also make adding another database pretty easy. > > -- > > Matthew Kent <mk...@ma...> > > http://magoazul.com > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by: Beat the post-holiday blues > > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > > _______________________________________________ > > Nagios-db-devel mailing list > > Nag...@li... > > https://lists.sourceforge.net/lists/listinfo/nagios-db-devel > > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Nagios-db-devel mailing list > Nag...@li... > https://lists.sourceforge.net/lists/listinfo/nagios-db-devel |
From: Matthew K. <mk...@ma...> - 2005-01-17 02:07:48
|
On Fri, 2005-01-14 at 03:21, Matthew Kent wrote: > > So, what do you think ? Is it worth the effort ? Else I look for other > > people to help my find out why the segfault and maybe help with > > abstracting the DB code in the UI. > > I'll be setting up the postgres module this weekend and will let you > know how it goes. > Verified that the postgres module compiles and works as expected on debian unstable. As mentioned, must be the libraries. -- Matthew Kent <mk...@ma...> http://magoazul.com |
From: Tim V. <dj...@ro...> - 2005-01-19 14:11:27
|
On Sun, 16 Jan 2005, Matthew Kent wrote: > Verified that the postgres module compiles and works as expected on > debian unstable. > > As mentioned, must be the libraries. Hi guys, I've been testing some more and I'm not really making any progress. So a bit more about my platform and what I'm seeing. Currently I'm testing on a FC1 system. This has postgres version 7.3.4. I've installed the regular rpms. So everything is/should be installed correctly. I've ofcourse needed to change the compile rule. This is what I'm using : gcc -g -O2 -o inserter.o inserter.c -shared -I /usr/include/nagios -I/usr/include/pgsql -lpq I've then started from a empty database. When I then start nagios I get this error : WARNING: Error occurred while executing PL/pgSQL function append_to_hostgroup line 9 at SQL statement Finaly I get a segfault at the PQclear function for the processStatus call for the host data. I someone knows a good way to debug that would really help. I'll will try again on a RHEL3 system in de coming days since the actual production server will be a RHEL3. Kind regards, Tim -- Tim Verhoeven - dj...@ro... - 0479 / 88 11 83 /* This is total bullshit: */ linux-2.6.6/drivers/video/sis/init301.c |
From: Ben <be...@si...> - 2005-01-19 16:38:31
|
On Jan 19, 2005, at 6:11 AM, Tim Verhoeven wrote: > On Sun, 16 Jan 2005, Matthew Kent wrote: > >> Verified that the postgres module compiles and works as expected on >> debian unstable. >> >> As mentioned, must be the libraries. > > Hi guys, > > I've been testing some more and I'm not really making any progress. So > a bit more about my platform and what I'm seeing. > > Currently I'm testing on a FC1 system. This has postgres version > 7.3.4. I've installed the regular rpms. So everything is/should be > installed correctly. I've ofcourse needed to change the compile rule. > This is what I'm using : > > gcc -g -O2 -o inserter.o inserter.c -shared -I /usr/include/nagios > -I/usr/include/pgsql -lpq That should be fine. Just to be sure what's actually getting used, would you run an ldd on inserter.o and see what the linker will add at runtime? > I've then started from a empty database. When I then start nagios I > get this error : > > WARNING: Error occurred while executing PL/pgSQL function > append_to_hostgroup line 9 at SQL statement If I'm reading it right, that means that this line is failing: select into thisHostID id FROM host WHERE name = thisHostName; That really shouldn't fail. Try turning on debug logging on your postgres server and see what it says about things. > Finaly I get a segfault at the PQclear function for the processStatus > call for the host data. > > I someone knows a good way to debug that would really help. > > I'll will try again on a RHEL3 system in de coming days since the > actual production server will be a RHEL3. Does it always crash at the same spot? I always hate it when people give this answer, but perhaps you are looking at the handiwork of a bad stick of ram? Anyway, you can try this for debugging: 1. load nagios in a debugger 2. put a breakpoint in nagios after it loads the neb modules (sorry, don't know where that is, but it shouldn't be hard to find) 3. run nagios 4. when you hit the breakpoint, put another breakpoint at the place in inserter.o where it consistently crashes. 5. continue again, and investigate what's going on at the crash point. It's possible that maybe the result which PQclear is trying to clear is null. I cannot recall at the moment if PQclear(0) will result in badness. |
From: Tim V. <dj...@ro...> - 2005-01-20 16:26:45
|
On Wed, 19 Jan 2005, Ben wrote: ...snip... >> I'm using : >> >> gcc -g -O2 -o inserter.o inserter.c -shared -I /usr/include/nagios >> -I/usr/include/pgsql -lpq > > That should be fine. Just to be sure what's actually getting used, would you > run an ldd on inserter.o and see what the linker will add at runtime? This is the output from ldd, looks fine to me : libpq.so.3 => /usr/lib/libpq.so.3 (0x009b8000) libc.so.6 => /lib/tls/libc.so.6 (0x00111000) libssl.so.4 => /lib/libssl.so.4 (0x0027b000) libcrypto.so.4 => /lib/libcrypto.so.4 (0x003cf000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x0032a000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x0024a000) libresolv.so.2 => /lib/libresolv.so.2 (0x00e9d000) libnsl.so.1 => /lib/libnsl.so.1 (0x002b0000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00314000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x007e1000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x005d9000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00f5c000) libdl.so.2 => /lib/libdl.so.2 (0x0068a000) libz.so.1 => /usr/lib/libz.so.1 (0x004c1000) >> I've then started from a empty database. When I then start nagios I get >> this error : ...snip... > That really shouldn't fail. Try turning on debug logging on your postgres > server and see what it says about things. Enabling some extensive logging helped. I've found a couple of issues in the stored procedures. One in host.sql is already fixed in CVS. This is the other : diff -u -r1.3 restart.sql --- restart.sql 16 Jan 2005 20:21:43 -0000 1.3 +++ restart.sql 20 Jan 2005 16:23:32 -0000 @@ -28,7 +28,7 @@ thisHostID int; BEGIN -- get the host id. If this is a new host, insert the host and get the id - select into thisHostID id FROM host WHERE name = thisHostName; + select into thisHostID id FROM host WHERE name = hostName; if thisHostID is not null then >> Finaly I get a segfault at the PQclear function for the processStatus call >> for the host data. ...snip... > It's possible that maybe the result which PQclear is trying to clear is null. > I cannot recall at the moment if PQclear(0) will result in badness. The error is always at the same place the PQclear in processStatus. I've did a run with gdb and the segfault occurs in : Program received signal SIGSEGV, Segmentation fault. 0x0039d50d in malloc_consolidate () from /lib/tls/libc.so.6 That seems a strange place for a segfault to happen, so I'm a bit lost what to make of it. Kind regards, Tim -- Tim Verhoeven - dj...@ro... - 0479 / 88 11 83 /* This is total bullshit: */ linux-2.6.6/drivers/video/sis/init301.c |
From: Ben <be...@si...> - 2005-01-14 17:00:46
|
Well, first of, thanks, and second off, that sucks. Can you tell me a little bit about your environment? Perhaps that might help explain things. I'd like to keep things as simple as possible, so I'm hesitant to make the database insertion happen by calling another layer. Yes, it would give more flexibility to how data gets inserted, but really, that process should almost never change once working, and it would also give another point of failure, another potential bottleneck, and certainly more latency in insertions. The fact that querify() doesn't work and that PQclear crashes your system leads me to think that you may be having problems with your postgres libs, because querify() does call PQescapeString() before it writes the final '. What libs are you linking against? On Jan 14, 2005, at 5:30 AM, Tim Verhoeven wrote: > Hi guys, > > First a word of thanks for so quickly creating these database plugins > for Nagios 2. I'm also converting our monitoring infrastructure from a > old netsaint to nagios 2. And for certain things like reports we need > the databse integration. > > So I've been trying to get your module to work. But I can't get it to > run. I always get a segfault. I'm currently trying it to work with > postgres 7.3.4. I first found out that the querify function was not > working. All strings were missing the final '. So I just removed the > piece of code that sets them and added them myself to the printf > statements. That fixed the first segfault. > > Then I'm still getting a segfault at the PQclear at the end of the > processtatus function. And I'm unable to find out why. The status of > the query is ok, no error. > > Getting a bit frustated about not being able to test and help out with > this I've had another idea. Why not change the code/ add a 3 > module/... to call external PHP code that does the actual DB work. It > is pretty simple to make commands out of PHP code (see pear for > example). > > This would allow at the beginning to test and develop much faster > since no recompiles are needed. Just chaning the PHP code is enough. > And with PHP you can also very easy do DB abstraction and that kind of > stuff. > Then later, when the code is stable enough, you can port the PHP code > to C to gain performance. > > So, what do you think ? Is it worth the effort ? Else I look for other > people to help my find out why the segfault and maybe help with > abstracting the DB code in the UI. > > Kind regards, > Tim > > -- > Tim Verhoeven - dj...@ro... - 0479 / 88 11 83 > > /* This is total bullshit: */ > linux-2.6.6/drivers/video/sis/init301.c > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Nagios-db-devel mailing list > Nag...@li... > https://lists.sourceforge.net/lists/listinfo/nagios-db-devel |
From: Ben <be...@si...> - 2005-01-20 16:37:08
|
On Jan 20, 2005, at 8:26 AM, Tim Verhoeven wrote: > Enabling some extensive logging helped. I've found a couple of issues > in the stored procedures. One in host.sql is already fixed in CVS. > This is the other : > > diff -u -r1.3 restart.sql > --- restart.sql 16 Jan 2005 20:21:43 -0000 1.3 > +++ restart.sql 20 Jan 2005 16:23:32 -0000 > @@ -28,7 +28,7 @@ > thisHostID int; > BEGIN > -- get the host id. If this is a new host, insert the host > and get the id > - select into thisHostID id FROM host WHERE name = thisHostName; > + select into thisHostID id FROM host WHERE name = hostName; > > if thisHostID is not null > then > Doh! Good catch. I wonder why I was never bit by this..... Well, regardless, the fix is now in CVS and I bet the reason you're crashing is because I've been too lazy and have not added error checking to the neb module. That's gonna change as soon as I get into work (assuming no fires... haha). But after you fixed this stored proc are you still crashing? |
From: Tim V. <dj...@ro...> - 2005-01-20 16:46:11
|
On Thu, 20 Jan 2005, Ben wrote: > Doh! Good catch. I wonder why I was never bit by this..... > > Well, regardless, the fix is now in CVS and I bet the reason you're crashing > is because I've been too lazy and have not added error checking to the neb > module. That's gonna change as soon as I get into work (assuming no fires... > haha). But after you fixed this stored proc are you still crashing? Yep, I'm still crashing here :-) I've got no more errors from pgsql. But still the crash at PQclear. So it must be some cleanup issue, something left behind, this is probably also why the segfault is at malloc_consolidate (whatever that does). Tim -- Tim Verhoeven - dj...@ro... - 0479 / 88 11 83 /* This is total bullshit: */ linux-2.6.6/drivers/video/sis/init301.c |
From: Ben <be...@si...> - 2005-01-20 17:23:05
|
I believe malloc_consolidate consolidates the free memory segments malloc can hand out. But that's neither here nor there.... I'll add some PQexec error checking into CVS and we'll see what that does for you. On Thu, 20 Jan 2005, Tim Verhoeven wrote: > On Thu, 20 Jan 2005, Ben wrote: > > > Doh! Good catch. I wonder why I was never bit by this..... > > > > Well, regardless, the fix is now in CVS and I bet the reason you're crashing > > is because I've been too lazy and have not added error checking to the neb > > module. That's gonna change as soon as I get into work (assuming no fires... > > haha). But after you fixed this stored proc are you still crashing? > > Yep, I'm still crashing here :-) I've got no more errors from pgsql. But > still the crash at PQclear. So it must be some cleanup issue, something > left behind, this is probably also why the segfault is at > malloc_consolidate (whatever that does). > > Tim > > -- > Tim Verhoeven - dj...@ro... - 0479 / 88 11 83 > > /* This is total bullshit: */ > linux-2.6.6/drivers/video/sis/init301.c > > |
From: Ben <be...@si...> - 2005-01-20 19:00:26
|
Okay, well, there's a new postgres inserter.c checked into cvs. I now check the query result to see if it succeeded, and if not, log it. I'm not at all clear why PQclear() would be crashing, but perhaps the added logging will show something. I also started compiling with -Wall, which caught some printf sloppiness, but that shouldn't have done anything bad. On Thu, 20 Jan 2005, Tim Verhoeven wrote: > On Thu, 20 Jan 2005, Ben wrote: > > > Doh! Good catch. I wonder why I was never bit by this..... > > > > Well, regardless, the fix is now in CVS and I bet the reason you're crashing > > is because I've been too lazy and have not added error checking to the neb > > module. That's gonna change as soon as I get into work (assuming no fires... > > haha). But after you fixed this stored proc are you still crashing? > > Yep, I'm still crashing here :-) I've got no more errors from pgsql. But > still the crash at PQclear. So it must be some cleanup issue, something > left behind, this is probably also why the segfault is at > malloc_consolidate (whatever that does). > > Tim > > -- > Tim Verhoeven - dj...@ro... - 0479 / 88 11 83 > > /* This is total bullshit: */ > linux-2.6.6/drivers/video/sis/init301.c > > |
From: Tim V. <dj...@ro...> - 2005-01-24 15:41:50
Attachments:
inserter.c.diff
|
On Thu, 20 Jan 2005, Ben wrote: > Okay, well, there's a new postgres inserter.c checked into cvs. I now > check the query result to see if it succeeded, and if not, log it. I'm not > at all clear why PQclear() would be crashing, but perhaps the added > logging will show something. > > I also started compiling with -Wall, which caught some printf sloppiness, > but that shouldn't have done anything bad. Hi Ben, Since I've been playing with a copy of the inserter code to test my things and because of your new inserter code in CVS, I've went to try your code again so all my changes were out. And the first problem I've run into getting inserter going again was the querify function again. Somehow it always fails to add ' and the null char at the end. So I focused a bit on debugging this. Well the fix was pretty simple and the big benefit was that all of a sudden everything started working. No more segfaults. Attached is a diff to the CVS version with changes. The fix is to give PQescapeString the length of the from string and not the to string. A second change I made is to add 3 instead of 2 to the length of the to string. This since we are adding 2 ' characters and you already have to do +1 according to the pgsql docs. All the rest of the changes are just some costmetic changes to the log messages. I find it cleaner this way. Feel free to discard them :-) One more thing is the pgsql connection parameters. These are at the moment hardcoded. I've seen in the nagios docs that you can also give parameters to NEB modules. It this something on your todo ? Or else I'm interrested to have a look at that. Now I start testing the UI :-) Regards, Tim -- Tim Verhoeven - dj...@ro... - 0479 / 88 11 83 /* This is total bullshit: */ linux-2.6.6/drivers/video/sis/init301.c |
From: Ben <be...@si...> - 2005-01-24 16:46:45
|
Doh! That's a good catch. And your cosmetic changes didn't both me, so it's all checked into cvs now. On Jan 24, 2005, at 7:41 AM, Tim Verhoeven wrote: > On Thu, 20 Jan 2005, Ben wrote: > >> Okay, well, there's a new postgres inserter.c checked into cvs. I now >> check the query result to see if it succeeded, and if not, log it. >> I'm not >> at all clear why PQclear() would be crashing, but perhaps the added >> logging will show something. >> >> I also started compiling with -Wall, which caught some printf >> sloppiness, >> but that shouldn't have done anything bad. > > Hi Ben, > > Since I've been playing with a copy of the inserter code to test my > things and because of your new inserter code in CVS, I've went to try > your code again so all my changes were out. > > And the first problem I've run into getting inserter going again was > the querify function again. Somehow it always fails to add ' and the > null char at the end. So I focused a bit on debugging this. Well the > fix was pretty simple and the big benefit was that all of a sudden > everything started working. No more segfaults. > > Attached is a diff to the CVS version with changes. The fix is to give > PQescapeString the length of the from string and not the to string. A > second change I made is to add 3 instead of 2 to the length of the to > string. This since we are adding 2 ' characters and you already have > to do +1 according to the pgsql docs. > > All the rest of the changes are just some costmetic changes to the log > messages. I find it cleaner this way. Feel free to discard them :-) > > One more thing is the pgsql connection parameters. These are at the > moment hardcoded. I've seen in the nagios docs that you can also give > parameters to NEB modules. It this something on your todo ? Or else > I'm interrested to have a look at that. > > Now I start testing the UI :-) > > Regards, > Tim > > -- > Tim Verhoeven - dj...@ro... - 0479 / 88 11 83 > > /* This is total bullshit: */ > linux-2.6.6/drivers/video/sis/init301.c > <inserter.c.diff> |
From: Tim V. <dj...@ro...> - 2005-01-24 21:42:58
|
Gents, I've finaly got my NEB module working, so I had a chance to play with the UI. It looks very nice and seems to be a good base to add things I need for our environment. So once again thanks for great work you already have done. But ofcourse being me I had to run into some sort of trouble :-) The first thing is this SQL error with the availability reports. (I'm using pgsql) Critical error follows: select coalesce(hostgroup.alias,'[no group]') as hostgroup,shgs.hostname,soft_state,round((duration::float/totaltime)::numeric,5) as percent from hostgroup,summarize_grouped_host_states_by_hostgroup( null,null,'{18}') shgs where shgs.groupid = hostgroup.id and shgs.configured = TRUE order by name,hostname [nativecode=ERROR: missing .. at end of SQL expression] The error (between the [] brackets) is always the same but ofcourse the actual select statement changes a bit for the 4 different availability reports. Since I'm not a hero with SQL and don't know pgsql at all I'm a bit lost here. Any ideas ? The second issue are the paths used by the html code. They seems to start with /neb/. Since I just made a alias in my httpd.conf to what comes out of CVS this doesn't really work. So my I offer 2 suggestions to fix this ? First is to make the prefix a config option. This addes some more php code inbetween the html code but keeps the absolute paths. Second is to change all path to the relative system. (That is what I did as a quick fix to get it working) The problem is ofcourse that it is not a clear system when you have many levels. I'm more than happy to implement either solution, or let me know if I mist another solution. Kind regards, Tim -- Tim Verhoeven - dj...@ro... - 0479 / 88 11 83 /* This is total bullshit: */ linux-2.6.6/drivers/video/sis/init301.c |
From: Matthew K. <mk...@ma...> - 2005-01-24 22:53:19
|
On Mon, 2005-01-24 at 21:42, Tim Verhoeven wrote: > The second issue are the paths used by the html code. They seems to start > with /neb/. Since I just made a alias in my httpd.conf to what comes out > of CVS this doesn't really work. So my I offer 2 suggestions to fix this ? > > First is to make the prefix a config option. This addes some more php code > inbetween the html code but keeps the absolute paths. > Second is to change all path to the relative system. (That is what I did > as a quick fix to get it working) The problem is ofcourse that it is not a > clear system when you have many levels. > > I'm more than happy to implement either solution, or let me know if I mist > another solution. I'll be sending up some big changes to the UI soon (taking a bit longer than expected) and will be sure to include the path option. As to that sql error, I'll take a look this evening if Ben hasn't gotten to it already. -- Matthew Kent <mk...@ma...> http://magoazul.com |
From: Ben <be...@si...> - 2005-01-25 19:20:51
|
On Mon, 24 Jan 2005, Matthew Kent wrote: > I'll be sending up some big changes to the UI soon (taking a bit longer > than expected) and will be sure to include the path option. Damn, I'd better get my UI fixes in soon, then. :) |
From: Ben <be...@si...> - 2005-01-25 19:20:15
|
On Mon, 24 Jan 2005, Tim Verhoeven wrote: > Gents, > > I've finaly got my NEB module working, so I had a chance to play with the > UI. It looks very nice and seems to be a good base to add things I need > for our environment. So once again thanks for great work you already have > done. Well, I'm glad to hear that it's useful to more than just me. > Critical error follows: > select coalesce(hostgroup.alias,'[no group]') as > hostgroup,shgs.hostname,soft_state,round((duration::float/totaltime)::numeric,5) > as percent from hostgroup,summarize_grouped_host_states_by_hostgroup( > null,null,'{18}') shgs where shgs.groupid = hostgroup.id and > shgs.configured = TRUE order by name,hostname [nativecode=ERROR: missing > .. at end of SQL expression] So, I tried to run this in psql and had no problem. I haven't had a problem with the page generation, either. I assume you get the same error if you copy that SQL and run it in psql? > The second issue are the paths used by the html code. They seems to start > with /neb/. Since I just made a alias in my httpd.conf to what comes out > of CVS this doesn't really work. So my I offer 2 suggestions to fix this ? Yeah, this was an ugly hack because I'm lazy. It sounds like Matthew already has a fix up his sleeve. |
From: Ben <be...@si...> - 2005-01-20 17:38:06
|
BTW, it looks like the reason this never bit me was because I fixed it and simply failed it check it in. Well, at least that's one mystery solved. On Thu, 20 Jan 2005, Ben wrote: > > On Jan 20, 2005, at 8:26 AM, Tim Verhoeven wrote: > > Enabling some extensive logging helped. I've found a couple of issues > > in the stored procedures. One in host.sql is already fixed in CVS. > > This is the other : > > > > diff -u -r1.3 restart.sql > > --- restart.sql 16 Jan 2005 20:21:43 -0000 1.3 > > +++ restart.sql 20 Jan 2005 16:23:32 -0000 > > @@ -28,7 +28,7 @@ > > thisHostID int; > > BEGIN > > -- get the host id. If this is a new host, insert the host > > and get the id > > - select into thisHostID id FROM host WHERE name = thisHostName; > > + select into thisHostID id FROM host WHERE name = hostName; > > > > if thisHostID is not null > > then > > > > Doh! Good catch. I wonder why I was never bit by this..... > > Well, regardless, the fix is now in CVS and I bet the reason you're > crashing is because I've been too lazy and have not added error > checking to the neb module. That's gonna change as soon as I get into > work (assuming no fires... haha). But after you fixed this stored proc > are you still crashing? > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Nagios-db-devel mailing list > Nag...@li... > https://lists.sourceforge.net/lists/listinfo/nagios-db-devel > |