Get your server issues fixed by our experts for a price starting at just 25 USD/Hour. Click here to register and open a ticket with us now!

Recent Posts

Pages: 1 ... 3 4 [5] 6 7 ... 10
General Discussion / Finding and preventing the DDOS attacks
« Last post by nidhinjo on November 01, 2018, 12:28:59 pm »
Below are some of the useful netstat commands to check during DDOS attack,
To list the connections to the target IPs (server's IP's) use the below command :

Code: [Select]
netstat -alpn | grep :80 | awk '{print $4}' |awk -F: '{print $(NF-1)}' |sort |uniq -c | sort -n

To list the connections from source IP's use the below command:

Code: [Select]
netstat -alpn | grep :80 | awk '{print $5}' |awk -F: '{print $(NF-1)}' |sort |uniq -c | sort -n

To see the state of each connection and the value use the below command:

Code: [Select]
netstat -an|grep ":80"|awk '/tcp/ {print $6}'|sort| uniq -c

You can use tcpdump to identify the attacker too:

Code: [Select]
tcpdump -c -n -i eth"x" -p host IP_Address

where x can be 0 or 1,n=number(100 or 1000). If it is a VPS, it can be venet0 too. Check the Output of ifconfig.

To check if a server is under a DoS attack with netstat, it’s common to use:

Code: [Select]
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n|wc -l
If the output of below command returns a result like 2000 or 3000 connections!, then obviously it’s very likely the server is under a DoS attack.

To detect a SYN flood with netstat :

Code: [Select]
netstat -nap | grep SYN | wc -l
If the output returns a value of 1032,1032 SYNs per second is quite a high number and except if the server is not serving let’s say 5000 user requests per second, therefore as the above output reveals it’s very likely the server is under attack, if however I get results like 100/200 SYNs, then obviously there is no SYN flood targetting

Checking if UDP Denial of Service is targetting the server :

Code: [Select]
netstat -nap | grep 'udp' | awk '{print $5}' | cut -d: -f1 | sort |uniq -c |sort -n
The above command will list information concerning possible UDP DoS.

The command can easily be accustomed also to check for both possible TCP and UDP denial of service, like so :

Code: [Select]
netstat -anp |grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
You can see the output as :


If after getting an IP that has too many connections to the server and is almost certainly a DoS host you would like to filter this IP.

Here is how I remove hosts to not be able to route packets to my server:

Code: [Select]
route add reject
The above command would null route the access of IP to my server.

Later on to look up for a null routed IP to my host, I use:

Code: [Select]
route -n |grep -i

Block the IPs with high connection above using CSF or APF firewall :

Code: [Select]
csf -d IP {reason}

apf -d IP

============================== :) ===================================
General Linux / How to find apache mpm module
« Last post by arunlalpr on October 24, 2018, 12:29:53 pm »
Kindly run the following command to find apache MPM module

#httpd -V | grep "Server MPM"

Server MPM:     prefork
Plesk / Plesk Onyx supported OS lists
« Last post by arunlalpr on October 18, 2018, 04:16:19 pm »
Plesk Onyx supports a limited number of 64 bit OS

* Debain 8,9
* Ubuntu 14.04,16.04,18.04
* RedHat Enterprise Linux/Centos/Cloudlinux 6,7
* Virtuozzo Linux 7

Plesk / Fix rpmdb: Thread died in Berkeley DB library
« Last post by vichithrakumart on September 11, 2018, 02:26:32 am »
This error occurs while upgrading the server packages and Plesk. This error shows because of the RPM database is opening failed.

Code: [Select]
yum update
rpmdb: Thread/process 16955/139826084484864 failed: Thread died in Berkeley DB library
error: db3 error(-30974) from dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db3 -  (-30974)
error: cannot open Packages database in /var/lib/rpm

Error: rpmdb open failed

Please try this to fix the issue

Code: [Select]
# mkdir /var/lib/rpm/backup
# cp -a /var/lib/rpm/__db* /var/lib/rpm/backup/
# rm -f /var/lib/rpm/__db.[0-9][0-9]*
# rpm --quiet -qa
# rpm --rebuilddb
# yum clean all
General Discussion / Programmatically get your public IP address with ipify
« Last post by Vineesh K P on September 08, 2018, 11:01:54 am »
Ever needed to get your public IP address programmatically? Then, you can use the service called "ipify". Using this service will give you the following advantages.
  • You can use it without limit (even if you're doing millions of requests per minute).
  • It's always online and available, and its infrastructure is powered by Heroku, which means that regardless of whether the server running the API dies, or if there's an enormous tornado which destroys half of the east coast, ipify will still be running!
  • It works flawlessly with both IPv4 and IPv6 addresses, so no matter what sort of technology you're using, there won't be issues.
  • ipify is completely open source.
  • No visitor information is ever logged. Period.
  • Lastly, ipify is funded by Randall Degges, so there's no need to worry about the domain name disappearing in three years or anything like that: ipify is here to stay!
You can learn more about it from here:
General Linux / Let’s Encrypt: Secure Apache Web Server on Ubuntu 16.04
« Last post by alext on September 08, 2018, 10:41:02 am »

Starting with Chrome 56, the browser developed by Google marks non-secure pages containing password and credit card input fields as Not Secure in the URL bar. It was almost one year ago, when the Mountain View giant announced this choice.
Of course, everybody knows that secure is better then insecure; but in this case, the big problem with HTTP is that it lacks a system for protecting communications between clients and servers. This exposes data to different kinds of attacks, for instance, the “Man in the middle” (MIM), in which the attacker intercepts your data. If you are using some transaction system with your bank, using credit card infos, or just entering a password to log in to a web site, this can become very dangerous.
This is why HTTPS exists (HTTP over TLS, or, HTTP over SSL, or, HTTP Secure).
If you are on Unixmen, you probably know what this means: SSL/TLS ensures encrypted connections.
So, if your job is to keep a web server up and running on, you should switch to HTTPS.
To encrypt the traffic between server and client, web servers use SSL certificates. Let’s Encrypt helps in obtaining and installing a trusted certificate for free.

In this tutorial we will see how to secure an Apache Web Server on Ubuntu 16.04 using Let’s Encrypt.
Install Let’s Encrypt

Let’s Encrypt provides a client software which will fetch certificates almost automatically. This software is called Certbot, and the developers have their Ubuntu repository with up to date versions.

So, first of all, we will add the repository:

Code: [Select]
# add-apt-repository ppa:certbot/certbot
Next, update apt packages list:

Code: [Select]
# apt-get update
At this point, install Certbot:

Code: [Select]
# apt-get install python-certbot-apache
Install SSL Certificate

Once the Certbot client is installed, we can use it to obtain and install a new certificate for our server. It is possible to use a single certificate for many subdomains (or even domains). This can be done just passing all the domains as certbot argument.

Code: [Select]
# certbot --apache -d -d
Certbot will present a step-by-step process to customize certificate options, and to enter information like email address. This last one will be used for key recovery. During the process it is possible to choice between which protocol to enable: both HTTP and HTTPS or HTTPS alone, which means that all requests will be automatically redirected. Of course, the best choice is to use only HTTPS, unless there are serious reasons to use unencrypted traffic to your server.
Testing Certificate

To verify the status of the SSL certificate, just go to the following link with a browser:

Certificates Renewal

Let’s Encrypt certificates last for 90 days, so it’s up to you to renew. Using Certbot, you can test the automatic renewal system with this command:

Code: [Select]
certbot renew --dry-run
If it works, you can add a cron or systemd job to manage automatic renewal.

We have seen how easy can be to install a SSL certificate on an Apache Web Server, running on top of Ubuntu 16.04, by using the software client provided by Let’s Encrypt. At this point, if you go with your browser to or you will see that the site will be correctly served through HTTPS.
General Linux / MySQL server runs out of memory or does not start
« Last post by akhilt on September 08, 2018, 10:35:36 am »
MySQL server runs out of memory or does not start

This article describes how to resolve a problem that may occur when you try to run MySQL server with a limited amount of memory.

You can resolve this problem by reducing the amount of memory that MySQL uses. To do this, modify the my.cnf configuration file and restart the MySQL server as follows:

1.  Use the nano or vi text editor to open the /etc/my.cnf file.

2.  Make the following changes to the my.cnf file. You may need to add some of these lines, or uncomment existing lines by removing the leading #.

Code: [Select]
set-variable = max_allowed_packet=1M
set-variable = thread_stack=64K
set-variable = table_cache=4
set-variable = sort_buffer=64K
set-variable = net_buffer_length=2K
set-variable = key_buffer_size=2095104

3. Save the changes to the my.cnf file.

4. Restart MySQL server. To do this, type the appropriate command for your Linux distribution:

 For CentOS and Fedora, type:

Code: [Select]
service mysqld restart
 For Debian and Ubuntu, type:

Code: [Select]
service mysql restart
Hope this article might help you someday,

Thank you!!  :)
General Linux / Resetting a forgotten MySQL root password in Linux
« Last post by akhilt on September 08, 2018, 10:27:29 am »
Resetting a forgotten MySQL root password in Linux

If you forgot MySQL root password, it can be recovered by booting the database in failsafe mode and then reset it.

To reset the root password for MySQL, follow these steps:

   1. Log in to your account using SSH.

   2. Stop the MySQL server using the appropriate command for your Linux distribution:

For CentOS and Fedora, type:

Code: [Select]
service mysqld stop
For Debian and Ubuntu, type:

Code: [Select]
service mysql stop

   3. Restart the MySQL server with the —skip-grant-tables option. To do this, type the following command:

Code: [Select]
mysqld_safe --skip-grant-tables &

   4. Log into MySQL using the following command:

Code: [Select]
   5. At the mysql> prompt, reset the password. To do this, type the following command, replacing NEW-PASSWORD with the new root password:
Code: [Select]
UPDATE mysql.user SET Password=PASSWORD('NEW-PASSWORD') WHERE User='root';
   6. At the mysql> prompt, type the following commands:

Code: [Select]

   7. Stop the MySQL server using the following command. You will be prompted to enter the new MySQL root password before the MySQL server shuts down:

Code: [Select]
mysqladmin -u root -p shutdown
   8. Start the MySQL server normally. To do this, type the appropriate command for your Linux distribution:

For CentOS and Fedora, type:

Code: [Select]
service mysqld start
For Debian and Ubuntu, type:

Code: [Select]
service mysql start

Hoping you find the article useful, Thank you!! ;D
General Linux / How To Monitor Remote Linux Host using Nagios 3.0
« Last post by akhilt on September 02, 2018, 11:09:34 am »
How To Monitor Remote Linux Host using Nagios 3.0

In this post, I’ll explain how to monitor a remote Linux host and the various services running on the remote host.


Following three steps will happen on a very high level when Nagios (installed on the nagios-servers) monitors a service (for e.g. disk space usage) on the remote Linux host.

1. Nagios will execute check_nrpe command on nagios-server and request it to monitor disk usage on remote host using check_disk command.

2. The check_nrpe on the nagios-server will contact the NRPE daemon on remote host and request it to execute the check_disk on remote host.

3. The results of the check_disk command will be returned back by NRPE daemon to the check_nrpe on nagios-server.

Following flow summarizes the above explanation:

Nagios Server (check_nrpe) —–> Remote host (NRPE deamon) —–> check_disk

Nagios Server (check_nrpe) <—– Remote host (NRPE deamon) <—– check_disk (returns disk space usage)

7 steps to install Nagios Plugins and NRPE on the remote host

1. Download Nagios Plugins and NRPE Add-on

Download following files from and move to /home/downloads:

   * nagios-plugins-1.4.11.tar.gz
   * nrpe-2.12.tar.gz

2. Create nagios account

Code: [Select]
[remotehost]# useradd nagios
[remotehost]# passwd nagios

3. Install nagios-plugin

Code: [Select]
[remotehost]# cd /home/downloads
[remotehost]# tar xvfz nagios-plugins-1.4.11.tar.gz
[remotehost]# cd nagios-plugins-1.4.11
[remotehost]# export LDFLAGS=-ldl

[remotehost]# ./configure --with-nagios-user=nagios --with-nagios-group=nagios --enable-redhat-pthread-workaround
[remotehost]# make
[remotehost]# make install

[remotehost]# chown nagios.nagios /usr/local/nagios
[remotehost]# chown -R nagios.nagios /usr/local/nagios/libexec/

Note: On Red Hat, For me the ./configure command was hanging with the the message: “checking for redhat spopen problem…”. Add --enable-redhat-pthread-workaround to the ./configure command as a work-around for the above problem.

4. Install NRPE

Code: [Select]
[remotehost]# cd /home/downloads
[remotehost]# tar xvfz nrpe-2.12.tar.gz
[remotehost]# cd nrpe-2.12

[remotehost]# ./configure
[remotehost]# make all
[remotehost]# make install-plugin
[remotehost]# make install-daemon
[remotehost]# make install-daemon-config
[remotehost]# make install-xinetd

5. Setup NRPE to run as daemon (i.e as part of xinetd):

Modify the /etc/xinetd.d/nrpe to add the ip-address of the Nagios monitoring server to the only_from directive. Note that there is a space after the and the nagios monitoring server ip-address (in this example, nagios monitoring server ip-address is:

Code: [Select]
       only_from       =
Modify the /etc/services and add the following at the end of the file.

Code: [Select]
       nrpe 5666/tcp # NRPE
Start the service

Code: [Select]
       [remotehost]#service xinetd restart
Verify whether NRPE is listening

Code: [Select]
[remotehost]# netstat -at | grep nrpe
       tcp 0      0 *:nrpe *:*                         LISTEN

Verify to make sure the NRPE is functioning properly

Code: [Select]
[remotehost]# /usr/local/nagios/libexec/check_nrpe -H localhost
NRPE v2.12

6. Modify the /usr/local/nagios/etc/nrpe.cfg

The nrpe.cfg file located on the remote host contains the commands that are needed to check the services on the remote host. By default the nrpe.cfg comes with few standard check commands as samples. check_users and check_load are shown below as an example.

Code: [Select]
command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10
command[check_load]=/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20

In all the check commands, the “-w” stands for “Warning” and “-c” stands for “Critical”. for e.g. in the check_disk command below, if the available disk space gets to 20% of less, nagios will send warning message. If it gets to 10% or less, nagios will send critical message. Change the value of “-c” and “-w” parameter below depending on your environment.

Code: [Select]
command[check_disk]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/hda1
Note: You can execute any of the commands shown in the nrpe.cfg on the command line on remote host and see the results for yourself. For e.g. When I executed the check_disk command on the command line, it displayed the following:

Code: [Select]
[remotehost]#/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/hda1
DISK CRITICAL - free space: / 6420 MB (10% inode=98%);| /=55032MB;51792;58266;0;64741

In the above example, since the free disk space on /dev/hda1 is only 10% , it is displaying the CRITICAL message, which will be returned to nagios server.

4 Configuration steps on the Nagios monitoring server to monitor remote host:

1. Download NRPE Add-on

Download nrpe-2.12.tar.gz from and move to /home/downloads:

2. Install check_nrpe on the nagios monitoring server

Code: [Select]
[nagios-server]# tar xvfz nrpe-2.12.tar.gz
[nagios-server]# cd nrpe-2.1.2
[nagios-server]# ./configure
[nagios-server]# make all
[nagios-server]# make install-plugin

./configure will give a configuration summary as shown below:

*** Configuration summary for nrpe 2.12 05-31-2008 ***:

General Options:
NRPE port: 5666
NRPE user: nagios
NRPE group: nagios
Nagios user: nagios
Nagios group: nagios

Note: I got the “checking for SSL headers… configure: error: Cannot find ssl headers” error message while performing ./configure. Install openssl-devel as shown below and run the ./configure again to fix the problem.

Code: [Select]
[nagios-server]# rpm -ivh openssl-devel-0.9.7a-43.16.i386.rpm krb5-devel-1.3.4-47.i386.rpm zlib-devel- e2fsprogs-devel-1.35-12.5.
warning: openssl-devel-0.9.7a-43.16.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e
Preparing… ########################################### [100%]
1:e2fsprogs-devel ########################################### [ 25%]
2:krb5-devel ########################################### [ 50%]
3:zlib-devel ########################################### [ 75%]
4:openssl-devel ########################################### [100%]

Verify whether nagios monitoring server can talk to the remotehost.

Code: [Select]
[nagios-server]#/usr/local/nagios/libexec/check_nrpe -H
NRPE v2.12

Note: in the ip-address of the remotehost where the NRPE and nagios plugin was installed as explained in Section II above.

3. Create host and service definition for remotehost

Create a new configuration file /usr/local/nagios/etc/objects/remotehost.cfg to define the host and service definition for this particular remotehost. It is good to take the localhost.cfg and copy it as remotehost.cfg and start modifying it according to your needs.

host definition sample:

Code: [Select]
define host{
use linux-server
host_name remotehost
alias Remote Host
contact_groups admins

Service definition sample:

Code: [Select]
define service{
use generic-service
service_description Root Partition
contact_groups admins
check_command check_nrpe!check_disk

Note: In all the above examples, replace remotehost with the corresponding hostname of your remotehost.

4. Restart the nagios service

Restart the nagios as shown below and login to the nagios web (http://nagios-server/nagios/) to verify the status of the remotehost linux sever that was added to nagios for monitoring.

Code: [Select]
[nagios-server]# service nagios reload
Thank you for reading my article, Have a nice day!!
General Linux / Nagios Command Line Options Explained
« Last post by akhilt on September 02, 2018, 10:32:16 am »
Nagios Command Line Options Explained

This article explains various command line options that are available for the Nagios command.

1. Start Nagios Daemon Using nagios -d

Typically you would execute “service nagios start” to start the Nagios daemon, which really calls the /etc/rc.d/init.d/nagios script.

You’ll see the following line inside the /etc/rc.d/init.d/nagios script for the Nagios startup:

Code: [Select]
$NagiosBin -d $NagiosCfgFile
So, you can also manually start Nagios daemon as shown below.

Code: [Select]
# /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
The advantage of manually starting the Nagios daemon is that you can run two Nagios instance on one server. If you like to run a small test instance where you can play around with various configuration files, and Nagios options, create a nagios-test.cfg that points to different configuration object directories than the nagios.cfg, and then start the test instance using nagios-test.cfg file as shown below.

Code: [Select]
# /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios-test.cfg
2. Verify Nagios Configurations Using nagios -v

Anytime you make changes to the configuration files, before you restart the Nagios daemon, verify the configuration changes (for syntax errors, and other invalid configuration errors) using nagios -v option as shown below.

Code: [Select]
# /usr/local/nagios/bin/nagios -v  /usr/local/nagios/etc/nagios.cfg
Reading configuration data...
Read main config file okay...

Processing object config file '/usr/local/nagios/etc/objects/commands.cfg'...
Processing object config file '/usr/local/nagios/etc/objects/contacts.cfg'...
Processing object config file '/usr/local/nagios/etc/objects/timeperiods.cfg'...
Processing object config file '/usr/local/nagios/etc/objects/templates.cfg'...
Processing object config directory '/usr/local/nagios/etc/servers'...
Read object config files okay...

Running pre-flight check on configuration data...

Checking services...Checked 450 services.
Checking hosts...   Checked 135 hosts.
Checking contacts...Checked 12 contacts.

Checking for circular paths between hosts...
Checking for circular host and service dependencies...

Total Warnings: 0
Total Errors:   0
Things look okay - No serious problems were detected during the pre-flight check

If this finds any issues, it will give proper message about the issue. At the end this will also display the total count for both warnings and errors. Make sure it says 0 here.

3. Display Processing Info and Scheduling Info using nagios -s

When you have a huge configuration files with several objects, nagios might take little longer to start. Using nagios -s option, you can see how much time Nagios might spend procesing configuration files. This also gives an approximate estimation on how much time you might save if you cache the configuration objects. How to cache configuration objects during startup is explained in the next item.

Code: [Select]
# /usr/local/nagios/bin/nagios -s  /usr/local/nagios/etc/nagios.cfg
I’ve split the output of the above command into multiple sections as shown below.

Object configuration processing times section displays the following information. In this example, the total time it took to process the configuration objects is way less than a second. So, caching the objects might not give you any visible difference, even thought it says you could save 4.36% by caching the objects. When you have a huge configuration file, you’ll definitely see some high numbers here.

Code: [Select]
OBJECT CONFIG PROCESSING TIMES  (* = Potential for precache savings with -u option)
Read:                 0.002094 sec
Resolve:              0.000046 sec  *
Recomb Contactgroups: 0.000019 sec  *
Recomb Hostgroups:    0.000012 sec  *
Dup Services:         0.000017 sec  *
Recomb Servicegroups: 0.000001 sec  *
Duplicate:            0.000004 sec  *
Inherit:              0.000003 sec  *
Recomb Contacts:      0.000000 sec  *
Sort:                 0.000001 sec  *
Register:             0.000142 sec
Free:                 0.000021 sec
TOTAL:                0.002360 sec  * = 0.000103 sec (4.36%) estimated savings

Configuration verification times section displays the amount of time it will take to verify the configuration during startup.

Code: [Select]
CONFIG VERIFICATION TIMES          (* = Potential for speedup with -x option)
Object Relationships: 0.000102 sec
Circular Paths:       0.000001 sec  *
Misc:                 0.000117 sec
TOTAL:                0.000220 sec  * = 0.000001 sec (0.5%) estimated savings

Even scheduling times section displays the amount of time it will take while processing various events mentioned below.

Code: [Select]
Get service info:        0.000084 sec
Get host info info:      0.000023 sec
Get service params:      0.000009 sec
Schedule service times:  0.000124 sec
Schedule service events: 0.010329 sec
Get host params:         0.000001 sec
Schedule host times:     0.000029 sec
Schedule host events:    0.000003 sec
TOTAL:                   0.010602 sec

The following section displays both host and service scheduling information.

Code: [Select]
Total hosts:                     3
Total scheduled hosts:           3
Host inter-check delay method:   SMART
Average host check interval:     300.00 sec
Host inter-check delay:          100.00 sec
Max host check spread:           30 min
First scheduled check:           Sun Nov 27 10:40:44 2011
Last scheduled check:            Sun Nov 27 10:44:04 2011

Total services:                     8
Total scheduled services:           8
Service inter-check delay method:   SMART
Average service check interval:     600.00 sec
Inter-check delay:                  75.00 sec
Interleave factor method:           SMART
Average services per host:          2.67
Service interleave factor:          3
Max service check spread:           30 min
First scheduled check:              Sun Nov 27 10:44:29 2011
Last scheduled check:               Sun Nov 27 10:53:14 2011

Finally, the performance suggestions section will lists all possible performance tunning suggestions for your specific configurations files.
Code: [Select]
I have no suggestions - things look okay.

4. Pre-cache Nagios Config Objects using nagios -p

When you have a big configuration file with several objects, you might save enough time during Nagios startup by caching the configuration objects.

The precache configuration information will be stored in the /usr/local/nagios/var/objects.precache file. If you’ve never created the pre-cache configuration files before, this file will not be present. If you want to change the location of the precache file, change the precached_object_file directive in the nagios.cfg file.

To create the pre-cache configuration files, use -p option as shown below.

Code: [Select]
# /usr/local/nagios/bin/nagios -pv /usr/local/nagios/etc/nagios.cfg
After the above command, the objects.precache file will be created. If you view this file, you can see that all Nagios object definitions are listed here. As it says in the beginning of this precache file, do not modify this file manually. If you like to modify any Nagios object, modify the appropriate configuration file, and regenerate the pre-cache file again.

Code: [Select]
# more /usr/local/nagios/var/objects.precache
5. Use Pre-cached Nagios Config Objects using nagios -u

After creating the pre-cache objects as shown above, stop Nagios daemon, and start it using -u option as shown below. Instead of reading the nagios configuration files again, it will simply use the cached objects that were earlier created from the /usr/local/nagios/var/objects.precache directory.

Code: [Select]
# /usr/local/nagios/bin/nagios -ud /usr/local/nagios/etc/nagios.cfg
6. Skip Circular Path Check using nagios -x

During the startup, Nagios checks to make sure you don’t have any circular paths in any of your object definitions. During startup, Nagios will make sure it doesn’t end-up in any deadlock situation by verifying circular paths. If you have lot of configuration objects, the circular path check might take some time.

If you have a working Nagios configuration, that you are sure doesn’t have any circular paths, you can instruct Nagios to skip this check during startup using nagios -x as shown below.

Code: [Select]
/usr/local/nagios/bin/nagios -xd /usr/local/nagios/etc/nagios.cfg
For faster Nagios startup, use both -u and -x option together as shown below, which will use pre-cache objects and skip circular path checks.

Code: [Select]
/usr/local/nagios/bin/nagios -uxd /usr/local/nagios/etc/nagios.cfg
Thank you, if you enjoyed this article
Pages: 1 ... 3 4 [5] 6 7 ... 10