Knowledge Base
Knowlegebase articles
Welcome to SysOrb knowledge base. Her you will find detailed explanation on questions regarding SysOrb. The list is under continues development and new articles will be added. You can follow the links below or enter a "key word" to search all of the articles.
- Agent crashes
- Automatic rescan of all nodes in a domain
- Bandwidth consumption estimate
- Basic database tuning
- Can I customize the reports in SysOrb?
- Disabling specific checks
- Does SysOrb support SNMP traps?
- Explanation of the score keeper strategy.
- How does HTTP Netcheck work in SysOrb?
- How to automatically update alert group on all nodes to “As domain”
- How to backup SysOrb database
- How to change time interval value of agent_checkin_delay
- How to move the SysOrb server to a new server
- How to quickly set downtime on an agent
- I cannot get all of the "performance counters/cache" entries to appear in SysOrb what should I do?
- Migrating MIB information from one SysOrb installation to another
- Migrating the configuration of a Windows SysOrb server from 32 to 64 bits
- No empty blocks in meta database.
- Script to get a list of nodes which have no AlertGroup
- SysOrb agent is not checking in to the Sysorb server
- SysOrb agent stops checking in from a windows server with very long system uptime
- SysOrb server shuts down unexpectedly
- System uptime no longer updates on windows
- Unable to monitor hardware (fans, disks, temperatures etc.) on Windows
- Upgrading SysOrb on Windows
- Uploading a SysOrb database to Evalesco
- What does KiB and MiB mean?
- What is IPMI ?
- Windows agent late for check-in every hour
SysOrb server shuts down unexpectedly
The SysOrb web interface reports that it cannot contact the SysOrb server. A typical message looks like this: The SysOrb Servers are currently not ready to service user requests. Please check back later, or contact the server administrator if you suspect the servers are not intentionally down for maintenance.
You are unable to locate the "sysorbd.exe" process in the Taskmanager (Windows) or the "sysorb" process in top or prstat (UNIX).
The Windows Service Control Manager reports that the SysOrb service started and then stopped.
Please gather as much as possible of the following information and files and contact support.
All systems
Add all files you collect to a ZIP (or other compressed archive format) and upload the file to ftp://ftp.evalesco.com/upload/ .
When you contact support you should inform us that you have uploaded the data and what filename you used for the uploaded file.
Please always include the SysOrb servers log file "server.log".
Windows
In many cases when SysOrb crashes, one or more memory dump file(s) will be written. These files contain valuable information that can help find and fix the cause of the crash. Please collect these files.
To locate the dump files, the easiest approach is to inspect the windows EventLog (in Start->Run type in "eventvwr" and hit ) where an entry from "SysOrb" can usually be found in the Application log. This log entry should point you at the exact location of the dump files.
In case there is no eventlog entry, you should look for dump files in the SysOrb server installation directory. Here the dump files should be written as the name of the executable that crashed with a .dmp extension - for example "sysorb-dbms.dmp".
If there is no dump file(s) in the server installation directory, please look for a file named "evalesco.dmp" in the Windows System32 directory.
Please note that the Windows explorer may not display these files by default. You may have to change explorer's configuration to show all extensions in order to be able to locate the files.
If there are no dump files to be found, please look in the eventlog for possible causes of this. It may be that a full disk or other system problem prevents the dump files from being written. If this is the case, please resolve the issue that prevented the dump file(s) from being written and then attempt to reproduce the problem you are experiencing, then collect the dump files.
Please also include the text of any SysOrb eventlog entries when you contact support.
UNIX/Linux
In the event of a SysOrb server crash a core dump file may be written to the current working directory of the SysOrb process in question. These core dump files contain valuable information that can be used to find and fix the cause of the crash. Please collect any such files.
The working directory where the core dump files are written can be found in the SysOrb server configuration file. The following command should identify the directory:
grep "working_directory" /etc/sysorb/server.conf
core dump files are named differently on different UNIX systems, but generally the file names include the string "core".
If no core dump files can be found, this could be caused by
ulimit
settings preventing core dumps being written. The command
ulimit -c
will show you the maximum allowed size of core files on your system. Please ensure that this setting is set to "unlimited" and then reproduce the problem and look for core files again.
Also please check the system logger (syslog) log files for entries from "SysOrb" and include any such log entries when you contact support.
