Linux Tips, Tricks, Tutorials & Fixes

Kill Hung Puppet process . kill -9 `ps -ef |grep "puppet agent: applying configurat" |grep -ve grep |awk '{print $2}'` /etc/init.d/puppet restart ps -ef |grep -i puppet | grep -v grep

In the context of a route entry, it usually means the default route. In the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs.

On a Linux server, when it loses connectivity to underlying storage (even briefly), the server doesn’t typically crash. It keeps running, but switches all the storage to read-only. Most of the OS and applications are running in RAM, so you don’t necessarily see any issues right away. The main issue we see is the OS and applications hold things in the disk-write queues. When you force the reboot after the storage outage, the kernel gets out-of-whack because that disk queue couldn’t clear properly and now doesn’t match the disks. So, we have to reboot and log in with root password under maintenance mode and force a disk check on the root and app file-systems. Once that is done, the host comes back online without issue.

Recently, I came across the situation where my CentOS server was not booting and displaying Kernel panic error. I have followed the steps mentioned below to make the server online: I spawned the init as bash. This can be done by giving the following boot parameter.   Init=/bin/bash   Once we have the bash prompt we can remount the root partition in read write mode.   Mount –o remount,rw /   Then change the password:   Password root   Once the password is changed reboot the system. It will ask for the fsck and maintenance password. Enter newly changed maintenance password.