New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Glad to hear that it's working now.
@NickM What ever came of your discussion with Fran about using the buyvm+ free backup to host your openstatus page?
He said that it was fine to host status pages there. I don't think it'll be too good of an idea though because you'd need to copy the database file over to there, and you'd need some way to update it regularly. You'd essentially need a PHP version of openstatus-server, running on buyvm+. Probably better to just have your openstatus-server with a different provider in a different datacenter (or at the very least, on a different node).
I might build in some kind of clustering support for openstatus-server though, so you can have multiple servers updated by just one openstatus-client. Currently, you could run two instances of openstatus-client on each box, each with different configs, updating to different servers if you wanted to have a fallback in case the primary openstatus-server fails, but that's not very efficient.
colspan should be 7 because there are only 7 collumns
Indeed it should. Not a huge deal since it still renders properly, but I've fixed it in the branch for the next version.
I get "Unable to connect to the database - please try again later." error.
Both database file and folder are 666 and owned by www-data.
Sqlite and python installed.
Please help.
My configs:
Simplyfast: I had the same thing. Restart php by issuing
/etc/init.d/php-cgi restart
and you'll be good. SQLite gets installed when you install the openstatus app from apt, but it doesn't restart php to enable.Oh, thats easy, I've restarted NGINX instead.
TNX
Still stuck: http://46.105.166.104/index.php.
No RAM no DISK no UPTIME etc.
Did you edit openstatus-client.conf? Does your hostname entered match with the output of /bin/hostname?
Done with the hostname.
Thanks
How do you install client on CentOS?
@LivingSoul: Clone the git repo, available here. The only files you really need are openstatus-client and openstatus-client.conf (you'll probably want to make your own init script, or set up some other way for it to start at boot, I'm not quite sure how it's done on CentOS). Make sure you have python and the necessary modules installed. Put the conf file at /etc/openstatus/openstatus-client.conf and the openstatus-client file somewhere in your PATH.
@NickM: I get this error running openstatus-client on CentOS
The error above has been fixed. Now, I get this error:
Whew.. having a hard time trying to run the client on CentOS
but I've successfully ran scrd on the same box. Any ideas anyone?
What version of python does CentOS have? Seems like it might be 2.4, since that's the same error that you get trying to run the 2.6 version on 2.4. Use python 2.6.
i keep getting this: Could not connect to server: Connection refused
no idea what i am doing wrong
Looks awesome! Will try it out when I can!
It works really great, but sometimes the server "freezes", it stops updating status for unknown reason. When I restart openstatus-server it resumes normal operation.
It happened twice already, anything I can do to help you find out the reason if it happens again?
It happened once to me too.
Looks really nice, I got it working with lighttpd as I have no experience with nginx.
Have also seen the random freeze on the openstatus-server, would you like any logs or anything?
Sorry, but I haven't run into any issues with -server randomly freezing. Please send me the contents of /etc/openstatus/openstatus-server.log (though there's probably nothing useful in there). Also, please include the output of the following commands:
uname -a
python --version
Also helpful would be the contents of "outfile" after running:
strace -p PID -o outfile
while openstatus-server seems to be frozen (replace PID with the PID of the openstatus-server process).This looks great, I might have to give it a go.
I've just published packages for version 0.2.0 of OpenStatus. A standard
apt-get update && apt-get upgrade
should upgrade you to the latest versions if you have version 0.1.0 installed from my repository. For new installations on Debian and its derivatives, please see this page for installation instructions. If you're using another distro, I'll be uploading the new version to GitHub tomorrow.I recommend updating both clients and servers due to a change in how memory usage is gathered and represented. Some clients running version 0.1.0 - namely VPSes based on Xen, KVM, and OpenVZ on CentOS 6 nodes with vSwap off, along with bare-metal OS installations - that send their info to a server running version 0.2.0 will probably display memory usage incorrectly. OpenVZ clients on CentOS 5 or CentOS 6 nodes with vSwap on should not experience this issue, but you should still upgrade the client machines if you update the server.
If you've made customizations to your web interface, I recommend backing up the /usr/share/openstatus-server/ directory - the upgrade will overwrite any customizations.
Changes:
I'll be continuing to work on the programs - planned new features in upcoming versions include:
Everything has been tested on Debian 5 and 6, and both the server and client work properly for me, but I can't test the system under every set of conditions, so if you notice a problem, please let me know and I'll try to get it fixed. If you fix it on your own, please also let me know how you solved the problem. Thanks, and enjoy!
I think you have released v 0.2 to quickly. There are several issues:
You're right, I apparently did release it a little too early - I apologize. I tracked down the first issue, that's fixed. I forgot to increment a counter variable for the javascript.
Second issue: Can you tell me what exactly is being displayed, and what should be displayed? If it's displaying a number and that number seems wrong, what are you comparing it to? It should match the output of the "+/- buffers/cache" line of
free -m
. Also, please tell me more about your setup - is it OpenVZ, Xen, KVM?Third issue: This is probably related to the first issue. The faulty javascript that was being produced probably caused the browser to crash. Current Chrome stable version (running on Ubuntu) does not crash.
Version 0.2.1 is now available in the repo to address the first and third issue.
@NickM
Sever froze again. server log shows only a few json errors, but there are no timestamps so I have no idea when it happened or it has something to do with it. Btw, adding timestamps to the log might be useful.
Python version is 2.6.6, kernel is 2.6.32-238.12.1.el5.pony6-1 #3 SMP Fri Jun 3 16:37:31 PDT 2011 i686 GNU/Linux (BuyVM obviously)
strace only shows this:
This is still 0.1 version of the server.
Anything else I can do? I'll keep it "stuck" for now.
Just following all updates, waiting for the next stable release
I think I've figured out what the problem is. If the client is trying to send more than 1024 bytes, it's hanging. The server is expecting a maximum of 1024 bytes, so it's never getting the end of the data. Try increasing BUFFER_SIZE in /usr/bin/openstatus-server
I need to write some better socket handling code to handle this condition.
Ok, I hope that's it. I'll let you know if the server freezes again.