Red hat linux problems

9.2. Monitoring and Diagnosing Performance Problems

Red Hat Enterprise Linux 7 provides a number of tools that are useful for monitoring system performance and diagnosing performance problems related to the networking subsystem. This section outlines the available tools and gives examples of how to use them to monitor and diagnose network related performance issues.

9.2.1. ss

ss is a command-line utility that prints statistical information about sockets, allowing administrators to assess device performance over time. By default, ss lists open non-listening TCP sockets that have established connections, but a number of useful options are provided to help administrators filter out statistics about specific sockets.

9.2.2. ip

The ip utility lets administrators manage and monitor routes, devices, routing policies, and tunnels. The ip monitor command can continuously monitor the state of devices, addresses, and routes.

9.2.3. dropwatch

Dropwatch is an interactive tool that monitors and records packets that are dropped by the kernel.

9.2.4. ethtool

The ethtool utility allows administrators to view and edit network interface card settings. It is useful for observing the statistics of certain devices, such as the number of packets dropped by that device.

You can view the status of a specified device’s counters with ethtool -S and the name of the device you want to monitor.

9.2.5. /proc/net/snmp

The /proc/net/snmp file displays data that is used by snmp agents for IP, ICMP, TCP and UDP monitoring and management. Examining this file on a regular basis can help administrators identify unusual values and thereby identify potential performance problems. For example, an increase in UDP input errors ( InErrors ) in /proc/net/snmp can indicate a bottleneck in a socket receive queue.

9.2.6. Network Monitoring with SystemTap

The Red Hat Enterprise Linux 7 SystemTap Beginner’s Guide includes several sample scripts that are useful for profiling and monitoring network performance.

The following SystemTap example scripts relate to networking and may be useful in diagnosing network performance problems. By default they are installed to the /usr/share/doc/systemtap-client/examples/network directory.

Every 5 seconds, prints a list of processes (process identifier and command) with the number of packets sent and received and the amount of data sent and received by the process during that interval.

Every 5 seconds, prints the number of socket buffers freed at locations in the kernel. Use the —all-modules option to see symbolic names.

The latencytap.stp script records the effect that different types of latency have on one or more processes. It prints a list of latency types every 30 seconds, sorted in descending order by the total time the process or processes spent waiting. This can be useful for identifying the cause of both storage and network latency. Red Hat recommends using the —all-modules option with this script to better enable the mapping of latency events. By default, this script is installed to the /usr/share/doc/systemtap-client-version/examples/profiling directory.

Источник

14.3. Problems After Installation

After you finish the installation and reboot your system for the first time, it is possible that the system stops responding during the graphical boot sequence, requiring a reset. In this case, the boot loader is displayed successfully, but selecting any entry and attempting to boot the system results in a halt. This usually means a problem with the graphical boot sequence; to solve this issue, you must disable graphical boot. To do this, temporarily alter the setting at boot time before changing it permanently.

Procedure 14.3. Disabling Graphical Boot Temporarily

Start your computer and wait until the boot loader menu appears. If you set your boot loader timeout period to 0, hold down the Esc key to access it.

When the boot loader menu appears, use your cursor keys to highlight the entry you want to boot and press the e key to edit this entry’s options.

In the list of options, find the kernel line — that is, the line beginning with the keyword linux . On this line, locate the rhgb option and delete it. The option might not be immediately visible; use the cursor keys to scroll up and down.

Press F10 or Ctrl + X to boot your system with the edited options.

If the system started successfully, you can log in normally. Then you will need to disable the graphical boot permanently — otherwise you will have to perform the previous procedure every time the system boots. To permanently change boot options, do the following.

Procedure 14.4. Disabling Graphical Boot Permanently

# grubby --default-kernel /boot/vmlinuz-3.10.0-229.4.2.el7.ppc64

Use the grubby tool to remove the rhgb boot option from the default kernel, identified in the last step, in your GRUB2 configuration. For example:

# grubby --remove-args="rhgb" --update-kernel /boot/vmlinuz-3.10.0-229.4.2.el7.ppc64

After you finish this procedure, you can reboot your computer. Red Hat Enterprise Linux will not use the graphical boot sequence any more. If you want to enable graphical boot in the future, follow the same procedure, replacing the —remove-args=»rhgb» parameter with the —args=»rhgb» paramter. This will restore the rhgb boot option to the default kernel in your GRUB2 configuration.

See the Red Hat Enterprise Linux 7 System Administrator’s Guide for more information about working with the GRUB2 boot loader.

14.3.2. Booting into a Graphical Environment

If you have installed the X Window System but are not seeing a graphical desktop environment once you log into your system, you can start it manually using the startx command. Note, however, that this is just a one-time fix and does not change the log in process for future log ins.

To set up your system so that you can log in at a graphical login screen, you must change the default systemd target to graphical.target . When you are finished, reboot the computer. You will presented with a graphical login prompt after the system restarts.

Procedure 14.5. Setting Graphical Login as Default

# systemctl set-default graphical.target

Graphical login is now enabled by default — you will be presented with a graphical login prompt after the next reboot. If you want to reverse this change and keep using the text-based login prompt, execute the following command as root :

# systemctl set-default multi-user.target

For more information about targets in systemd , see the Red Hat Enterprise Linux 7 System Administrator’s Guide.

14.3.3. No Graphical User Interface Present

If you are having trouble getting X (the X Window System ) to start, it is possible that it has not been installed. Some of the preset base environments you can select during the installation, such as Minimal install or Web Server , do not include a graphical interface — it has to be installed manually.

If you want X , you can install the necessary packages afterwards. See the Knowledgebase article at https://access.redhat.com/site/solutions/5238 for information on installing a graphical desktop environment.

14.3.4. X Server Crashing After User Logs In

If you are having trouble with the X server crashing when a user logs in, one or more of your file systems can be full or nearly full. To verify that this is the problem you are experiencing, execute the following command:

The output will help you diagnose which partition is full — in most cases, the problem will be on the /home partition. The following is a sample output of the df command:

Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_rhel-root 20G 6.0G 13G 32% / devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.8G 2.7M 1.8G 1% /dev/shm tmpfs 1.8G 1012K 1.8G 1% /run tmpfs 1.8G 0 1.8G 0% /sys/fs/cgroup tmpfs 1.8G 2.6M 1.8G 1% /tmp /dev/sda1 976M 150M 760M 17% /boot /dev/dm-4 90G 90G 0 100% /home

In the above example, you can see that the /home partition is full, which causes the crash. You can make some room on the partition by removing unneeded files. After you free up some disk space, start X using the startx command.

For additional information about df and an explanation of the options available (such as the -h option used in this example), see the df(1) man page.

14.3.5. Is Your System Displaying Signal 11 Errors?

A signal 11 error, commonly known as a segmentation fault, means that a program accessed a memory location that was not assigned to it. A signal 11 error can occur due to a bug in one of the software programs that is installed, or faulty hardware.

If you receive a fatal signal 11 error during the installation, first make sure you are using the most recent installation images, and let Anaconda verify them to make sure they are not corrupted. Bad installation media (such as an improperly burned or scratched optical disk) are a common cause of signal 11 errors. Verifying the integrity of the installation media is recommended before every installation.

For information about obtaining the most recent installation media, see Chapter 2, Downloading Red Hat Enterprise Linux. To perform a media check before the installation starts, append the rd.live.check boot option at the boot menu. See Section 23.2.2, “Verifying Boot Media” for details.

Other possible causes are beyond this document’s scope. Consult your hardware manufacturer’s documentation for more information.

14.3.6. Unable to IPL from Network Storage Space (*NWSSTG)

If you are experiencing difficulties when trying to IPL from Network Storage Space (*NWSSTG), in most cases the reason is a missing PReP partition. In this case, you must reinstall the system and make sure to create this partition during the partitioning phase or in the Kickstart file.

14.3.7. The GRUB2 next_entry variable can behave unexpectedly in a virtualized environment

IBM Power System users booting their virtual environment with SLOF firmware must manually unset the next_entry grub environment variable after a system reboot. The SLOF firmware does not support block writes at boot time by design thus the bootloader is unable to clear this variable at boot time.

Источник