Check the logs

/var/log/messages, which stores logs from many native CentOS services, such as the kernel logger, the network manager, and many other services that don’t have their own log files. This log file tells you if there are kernel problems (kernel panic messages) or kernel limits violations, such as the number of currently open files, which can cause system problems. You can fix kernel misconfigurations by editing the file /etc/sysctl.conf and changing the value for the corresponding error.

/var/log/dmesg, which contains information about hardware found by the kernel drivers. It can help you troubleshoot hardware problems and missing drivers. You can also use the command /bin/dmesg for similar purposes. /bin/dmesg provides more detailed information in real time, while the log file keeps less information for historical purposes.

/var/log/audit/audit.log, which is the file in which the Linux Auditing System (auditd) writes its logs, including all SELinux information. If auditd is disabled, SELinux sends its logs to /var/log/messages. SELinux is a common suspect for any strange behavior and problems in CentOS. It is enabled by default in CentOS 6 and should not be frivolously disabled, as it is important for security. You can check its status with the command sestatus. A Wazi article about Linux server hardening covers the basics of SELinux, including how to adjust its policies in order to avoid problems.

Service- and application-specific logs – Many applications create logs in other places, and have options that control where and what to log. By default in CentOS the Apache web server logs in the directory /var/log/httpd/, mail servers log in /var/log/maillog, and MySQL logs in /var/log/mysqld.log. However, not all logs are located in the logs directory. Some applications, such as user-space programs, may not have privileges to write there. Others prefer to log inside their own root directory. You may need to consult an application’s manual to learn where it writes its logs.

If it’s gone down without logging anything, it might be power related so it’s not had the chance to log anything.

w command is used to show logged-in user names and what they are doing. The information will be read from /var/run/utmp file. The output of the w command contains the following columns:

Name of the user
User’s machine number or tty number
Remote machine address
User’s Login time
Idle time (not usable time)
Time used by all processes attached to the tty (JCPU time)
Time used by the current process (PCPU time)
Command currently getting executed by the users

Following options can be used for the w command:

-h Ignore the header information
-u Display the load average (uptime output)
-s Remove the JCPU, PCPU, and login time.

[root@austin ~]# w
 15:46:21 up 23 days, 1 min,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    66.226.xx.x    15:46    0.00s  0.06s  0.00s w

[root@austin ~]# w -h
root     pts/0    66.226.79.7      15:46    0.00s  0.06s  0.00s w -h

[root@austin ~]# w -u
 15:47:05 up 23 days, 2 min,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    66.226.79.7      15:46    0.00s  0.06s  0.00s w -u

[root@austin ~]# w -s
 15:47:23 up 23 days, 2 min,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM               IDLE WHAT
root     pts/0    66.226.79.7       0.00s w -s

2. Get the user name and process of logged in user using who and users command

who command is used to get the list of the usernames who are currently logged in. Output of the who command contains the following columns: user name, tty number, date and time, machine address.

[root@austin ~]# who
root     pts/0        2014-07-11 15:46 (66.226.79.7)

To get a list of all usernames that are currently logged in, use the following:

[root@austin ~]# who | cut -d' ' -f1 | sort | uniq
root

Users Command

users command is used to print the user name who are all currently logged in the current host. It is one of the command don’t have any option other than help and version. If the user using, ‘n’ number of terminals, the user name will shown in ‘n’ number of time in the output.

[root@austin ~]# users
root

3. Get the username you are currently logged in using whoami. whoami command is used to print the loggedin user name.

[root@austin ~]# whoami
root

whoami command gives the same output as id -un as shown below:

[root@austin ~]# id -un
root

who am i command will display the logged-in user name and current tty details. The output of this command contains the following columns: logged-in user name, tty name, current time with date and ip-address from where this users initiated the connection.

[root@austin ~]# who am i
root     pts/0        2014-07-11 15:46 (66.226.79.7)

[root@austin ~]# who mom likes
root     pts/0        2014-07-11 15:46 (66.226.79.7)

Warning: Don’t try “who mom hates” command.

Also, if you do su to some other user, this command will give the information about the logged in user name details.

4. Get the user login history at any time

last command will give login history for a specific username. If we don’t give any argument for this command, it will list login history for all users. By default this information will read from /var/log/wtmp file. The output of this command contains the following columns:

User name
Tty device number
Login date and time
Logout time
Total working time

[root@austin ~]# last
root     pts/0        10.1.xx.x    Sat Aug  3 06:49 - down   (00:01)

Instructions for 32 bit systems:

$ wget -c https://download.jitsi.org/jitsi/nightly/rpm/jitsi-2.5-5314.i686.rpm
$ sudo rpm -i jitsi-2.2-latest.i386.rpm

Instructions for 64 bit systems:

$ wget -c https://download.jitsi.org/jitsi/nightly/rpm/jitsi-2.5-5314.x86_64.rpm
$ sudo rpm -i jitsi-2.2-latest.x86_64.rpm

Root Cause Analysis

Root cause analysis (RCA) is a method of problem solving that tries to identify the root causes of faults or problems.

RCA practice tries to solve problems by attempting to identify and correct the root causes of events, as opposed to simply addressing their symptoms. Focusing correction on root causes has the goal of preventing problem recurrence. RCFA (Root Cause Failure Analysis) recognizes that complete prevention of recurrence by one corrective action is not always possible.

http://en.wikipedia.org/wiki/Root_cause_analysis