How to add a value to a select field in Ruby On Rails
Posted by Lennart | Filed under Hacking, Ruby On Rails
I’ll just leave this here: When you fill a select box directly from a array returned by .find(:all) you can add more values tothe select box this way:
Controller:
@hosts = Host.find(:all).collect {|p| [p.name, p.id] }
@hosts << ["None", nil]
View:
<dd>
<%= f.select :linkedhost, @hosts %>
<%= error_message_on(:service, :linkedhost) %>
</dd>
Tags: add, array, find, model, standard, value
Nasty bugs: std::logic_error because of NULL string
Posted by Lennart | Filed under Hacking, ScopePort
I recently changed the Warning::getConditions() method of ScopePort. It now takes two parameters:
- string hostid - The ID of the host on which the sensor to check is running
- string st - The ID of the sensor to check.
I started up ScopePort and got the following error after about 2-3 minutes:
terminate called after throwing an instance of ’std::logic_error’
what(): basic_string::_S_construct NULL not valid
Because of the time delay I searched for the error in the recently changed Warning::getConditions() method. I expected that an usual alarm was causing something to fail. But as my investigations went on I noticed that the time delay was exactly 180 seconds. Each time. So I thought about it and remembered that the onlineStateChecks() thread was going into full operations after 180 seconds (That is to give the clients time to send data.). I quickly found out where the error was caused: Just at the time of the Warning::getConditions() method call. The debugger didn’t even let me step into the method. It failed right at the method call. As it was pretty late and I had to get up early the next day I went to sleep and planned to ask a friend the next day.
The next morning. At the time I was explaining my Problem to the friend I already found the error. (Sometimes it is really better to go to bed…): When I updated the onlineStateChecks and clientHandler() threads to use the new method I made a mistake: I used the wrong column of the database result. This ended in 0 as second parameter. Exactly. Not “0″ but 0.
My friend explained me that the compiler was not complaining because he just accepted the 0 as a NULL string. I didn’t even look for wrong parameter types because I thought the compiler wouldn’t even think about compiling 0 as string. Lesson learnt. Thank you.
Here is a little example program that reproduces the error:
#include "TestClass.h"
using namespace std;
int main(){
TestClass test;
test.testMe("foo", 0);
return 0;
}
class TestClass {
public:
void testMe(string foo, string bar){
return;
}
};
Tags: bugs, c++, null, ScopePort, std::logic_error, string
Debbuging ScopePort service response time module
Posted by Lennart | Filed under Hacking, ScopePort
from my flickr.
Tags: code, debugging, eclipse, gnome, response time, ScopePort, screenshot, service, shell
Get the most information out of your GNU/Linux processes
Posted by Lennart | Filed under GNU/Linux, Hacking
Sometimes it is not easy to find out what process is currently slowing down your system or why the mouse is jumping over the screen when it is supposed to follow your hand movements in a kind of gliding motion. I have collected a list of tools to find out what processes consume the most of your resources and even how to get an indication of the reason for that.
CPU and memory usage: top/htop
Most of you may already know “top”. It is the first program to fire up if the system gets unsually slow. top shows you a list of processes - ordered by their memory and CPU usage.
/usr/bin/top
As an alternative there is an improved version of top: htop. It has many more options for sorting, searching or display and shows the general system usage in a clearly arranged way.
/usr/bin/htop
htop might not be a standard part of your distribution but it should be available in the repositories.
I/O usage: iotop
Sometimes programs slow down the system by using too much I/O resources (e.g. when extracting a really big tarball). When the programs don’t need much CPU resources for heavy I/O resources they might now show up in top or htop. If you want to find out e.g. what is currently hammering your hard disk buffers you can take a look at iotop: It displays processes sorted by I/O usage in a top-like way.
/usr/bin/iotop
iotop might not be a standard part of your distribution but it should be available in the repositories.
MySQL and Apache
Sometimes you want to know what consumes most of your MySQL or Apache resources.
If you want to know what queries are currently executed and in what state the operation is you can use the “SHOW PROCESSLIST;” SQL command in a MySQL shell:
SHOW PROCESSLIST;
If your Apache has heavy load you might want to know what requests/files cause this load. There is a program “apachetop” that provides this information:
/usr/bin/apachetop
apachetop might not be a standard part of your distribution but it should be available in the repositories.
Finding out more about rioting processes
So you found the process that consumes the resources? Here is the ultimate solution to find out more about the process: /bin/lsof (list open files)
Here are the possibly most useful lsof modes:
Show all open files of the process with given PID: lsof -p [PID]
Show all programs that have currently opened a file: lsof [file]
Show all programs that have currently opened a file in a given directory: lsof +D [directory]
Show all programs that have a socket related to a given port: lsof -i :[port]
lsof -p 3773
/bin/lsof +D /var/log
/bin/lsof -i :12200
Tags: apache. processes, cpu, directory, file, htop, iotop, lsof, memory, mysql, port, top, usage
How to get information about your own process
Posted by Lennart | Filed under *NIX, Hacking
If you want to get Information of your own process on a GNU/Linux system you should take a look at the /proc/self/ pseudo-directory. This directory contains information of the process that is reading it. You could also find out the PID of the process and read files in the /proc/[PID]/ directory. However, the /proc/self/ directory always keeps information of the process that is reading it.
Take a look at the proc manual pages to get an explanation of the files. (man proc) The most interesting may be /proc/self/status. It is a human readable version of the most values from /proc/self/stat and /proc/self/statm.
The /proc/ directory should be well known by every GNU/Linux system programmer as it contains a lot of useful information about your system and your processes.
Current state of ScopePort development
Posted by Lennart | Filed under Hacking, ScopePort
This is the first post in this blog. It will inform you about the current state of ScopePort development.
Right now there is only one developer. Me. I am writing the Server itself (C++), the Linux and *BSD clients (C++), the Web Interface (PHP) and everything else related to ScopePort.
Current screenshots can be found on ScopePort.org: http://scopeport.org/see-it
Where I am right now
The following parts of ScopePort are ready to go into the next phase:
- Web Interface layout and structure
- Web Interface sections: User management, adding/deleting/updating service checks and hosts, notification groups, blacklist, service check details and overview, host overview and details, log, graphs.
- Server: Thread handling, client handling, service checks (with protocol checks), notifications in case of errors, fallback modes in case of failed database server, check for “dead” clients that stopped sending sensor data,
- Client: Sensors, profile sensors,
What needs to be done to reach a feature freeze?
- Web Interface install tool
- New features: “Global severity level”, “public status” page and “user defined screens”
- General improvements in usability of the web interface
- More features that help you managing your servers. (Like the already completed features “Todo list” and “Detailed descriptions” that are available for every host)
- Packaging and correct GNU/Autotools usage for the server and client packages.
- remote.php API of the Web Interface that will be used by the ScopePort Console nCurses (which has no release plan yet)
What needs to be done to reach a public beta?
- Documentation
- Stability testing (especially checks for memory leaks)
- Security testing
- Testing of web interface in different browsers
- Checking for XHTML validity of web interface
Contact me if you are interested in joining development, beta testing or if you have questions.
Tags: Development, Hacking, Remote Monitoring, ScopePort
