mtpti5iD/redhat-docs_dataset huggingface dataset:
4.4. Identifying Contended User-Space Locks This section describes how to identify contended user-space locks throughout the system within a specific time period. The ability to identify contended user-space locks can help you investigate hangs that you suspect may be caused by futex contentions. Simply put, a futex contention occurs when multiple processes are trying to access the same region of memory. In some cases, this can result in a deadlock between the processes in contention, thereby appearing as an application hang. To do this, futexes.stp probes the futex system call. futexes.stp futexes.stp needs to be manually stopped; upon exit, it prints the following information: Name and ID of the process responsible for a contention The region of memory it contested How many times the region of memory was contended Average time of contention throughout the probe Example 4.17, "futexes.stp Sample Output" contains an excerpt from the output of futexes.stp upon exiting the script (after approximately 20 seconds). Example 4.17. futexes.stp Sample Output

Commands:
#! /usr/bin/env stap This script tries to identify contended user-space locks by hooking into the futex system call. global thread_thislock # short global thread_blocktime # global FUTEX_WAIT = 0 /*, FUTEX_WAKE = 1 */ global lock_waits # long-lived stats on (tid,lock) blockage elapsed time global process_names # long-lived pid-to-execname mapping probe syscall.futex { if (op != FUTEX_WAIT) next # don't care about WAKE event originator t = tid () process_names[pid()] = execname() thread_thislock[t] = USDuaddr thread_blocktime[t] = gettimeofday_us() } probe syscall.futex.return { t = tid() ts = thread_blocktime[t] if (ts) { elapsed = gettimeofday_us() - ts lock_waits[pid(), thread_thislock[t]] <<< elapsed delete thread_blocktime[t] delete thread_thislock[t] } } probe end { foreach ([pid+, lock] in lock_waits) printf ("%s[%d] lock %p contended %d times, %d avg us\n", process_names[pid], pid, lock, @count(lock_waits[pid,lock]), @avg(lock_waits[pid,lock])) }
[...] automount[2825] lock 0x00bc7784 contended 18 times, 999931 avg us synergyc[3686] lock 0x0861e96c contended 192 times, 101991 avg us synergyc[3758] lock 0x08d98744 contended 192 times, 101990 avg us synergyc[3938] lock 0x0982a8b4 contended 192 times, 101997 avg us [...]
12.2. Filesystem-Specific Information for fsck 12.2.1. ext2, ext3, and ext4 All of these filesytems use the e2fsck binary to perform filesystem checks and repairs. The filenames fsck.ext2 , fsck.ext3 , and fsck.ext4 are hardlinks to this same binary. These binaries are run automatically at boot time and their behavior differs based on the filesystem being checked and the state of the filesystem. A full filesystem check and repair is invoked for ext2, which is not a metadata journaling filesystem, and for ext4 filesystems without a journal. For ext3 and ext4 filesystems with metadata journaling, the journal is replayed in userspace and the binary exited. This is the default action as journal replay ensures a consistent filesystem after a crash. If these filesystems encounter metadata inconsistencies while mounted, they will record this fact in the filesystem superblock. If e2fsck finds that a filesystem is marked with such an error e2fsck will perform a full check after replaying the journal (if present). e2fsck may ask for user input during the run if the -p option is not specified. The -p option tells e2fsck to automatically do all repairs that may be done safely. If user intervention is required, e2fsck will indicate the unfixed problem in its output and reflect this status in the exit code. Commonly used e2fsck run-time options include: -n No-modify mode. Check-only operation. -b superblock Specify block number of an alternate superblock if the primary one is damaged. -f Force full check even if the superblock has no recorded errors. -j journal-dev Specify the external journal device, if any. -p Automatically repair or "preen" the filesystem with no user input. -y Assume an answer of "yes" to all questions. All options for e2fsck are specified in the e2fsck(8) manual page. The following five basic phases are performed by e2fsck while running: Inode, block, and size checks. Directory structure checks. Directory connectivity checks. Reference count checks. Group summary info checks. The e2image(8) utility can be used to create a metadata image prior to repair for diagnostic or testing purposes. The -r option should be used for testing purposes in order to create a sparse file of the same size as the filesystem itself. e2fsck can then operate directly on the resulting file. The -Q option should be specified if the image is to be archived or provided for diagnostic. This creates a more compact file format suitable for transfer.

Commands:
Chapter 24. Networking Cisco usNIC driver Cisco Unified Communication Manager (UCM) servers have an optional feature to provide a Cisco proprietary User Space Network Interface Controller (usNIC), which allows performing Remote Direct Memory Access (RDMA)-like operations for user-space applications. The libusnic_verbs driver, which is supported as a Technology Preview, makes it possible to use usNIC devices via standard InfiniBand RDMA programming based on the Verbs API. Cisco VIC kernel driver The Cisco VIC Infiniband kernel driver, which is supported as a Technology Preview, allows the use of Remote Directory Memory Access (RDMA)-like semantics on proprietary Cisco architectures. Trusted Network Connect Trusted Network Connect, supported as a Technology Preview, is used with existing network access control (NAC) solutions, such as TLS, 802.1X, or IPsec to integrate endpoint posture assessment; that is, collecting an endpoint's system information (such as operating system configuration settings, installed packages, and others, termed as integrity measurements). Trusted Network Connect is used to verify these measurements against network access policies before allowing the endpoint to access the network. SR-IOV functionality in the qlcnic driver Support for Single-Root I/O virtualization (SR-IOV) has been added to the qlcnic driver as a Technology Preview. Support for this functionality will be provided directly by QLogic, and customers are encouraged to provide feedback to QLogic and Red Hat. Other functionality in the qlcnic driver remains fully supported.

Commands:
4.3.14. Recreating a Volume Group Directory To recreate a volume group directory and logical volume special files, use the vgmknodes command. This command checks the LVM2 special files in the /dev directory that are needed for active logical volumes. It creates any special files that are missing and removes unused ones. You can incorporate the vgmknodes command into the vgscan command by specifying the mknodes argument to the vgscan command.

Commands:
B.20.2. RHEA-2010:0904 - fence-agents enhancement update An updated fence-agents package that adds support for new hardware and Red Hat Enterprise Virtualization is now available. Red Hat fence agents are a collection of scripts to handle remote power management for several devices. They allow failed or unreachable nodes to be forcibly restarted and removed from the cluster. Enhancements BZ# 642695 The package has been updated to provide a fencing agent that is able to communicate with Red Hat Enterprise Virtualization Manager, allowing virtual machines to be fenced. BZ# 643340 For Intelligent Platform Management Interface (IPMI) devices, the "power_wait" delay can now be adjusted in order to support newer iLO 3 firmware. BZ# 643515 Brocade 200E, Brocade 300, Brocade 4100, Brocade 4900, and Brocade 5100 fencing devices are now supported by the fence_brocade agent, and can be used with both Red Hat High Availability and Red Hat Resilient Storage. All users requiring any of the features listed above are advised to upgrade to this new package, which adds these enhancements.

Commands:
4.6.2. Modifying a Fence Device To modify a fence device, follow these steps: From the Fence Devices configuration page, click on the name of the fence device to modify. This displays the dialog box for that fence device, with the values that have been configured for the device. To modify the fence device, enter changes to the parameters displayed. Refer to Appendix A, Fence Device Parameters for more information. Click Apply and wait for the configuration to be updated.

Commands:
Chapter 29. Kernel RAID 4 and RAID 10 creation and activation fully supported In Red Hat Enterprise Linux 7.3, existing RAID4 or RAID10 logical volumes created with releases failed to activate. Additionally, users were instructed not to create new RAID4 logical volumes created under Red Hat Enterprise Linux 7.3 as these might fail to activate with later releases and updates. With this update, Red Hat Enterprise Linux 7.4 fully supports RAID 4 and RAID 10 creation and activation and rejects invalid RAID 4 and RAID 10 layouts which may have been created with Red Hat Enterprise Linux 7.3. (BZ#1385149) kdump now works with legacy type 12 NVDIMMs Previously, systems with legacy type 12 Non-Volatile Dual In-line Memory Modules (NVDIMMs), either real dual in-line memory modules (DIMMs), or emulated using the memmap=XG!YG kernel command line parameter, were unable to successfully capture a kernel crash dump. For systems with real NVDIMMs, attempts to capture a kernel crash dump occasionally resulted in data corruption. With this update, the underlying source code has been fixed, and the systems with legacy type 12 NVDIMMs can now capture the kernel crash dump as expected. (BZ#1351098) Creating a file that inherits ACLs no longer loses mask Previously, creating a file that inherited Access Control Lists (ACLs) caused the mask to be lost, unlike on a local file system. With this update, clients using NFSv4.2 can set the umask attribute when creating files to cause the server to apply umask always except when inheriting permissions from the parent directory. As a result, new NFS files get the same permissions as files created locally. Note that you need to apply this update on both your NFS clients and NFS servers, and mount with the -overs=4.2 parameter. (BZ#1217546)

Commands:
2.5. Software Collection Package Names The Software Collection package name consists of two parts: the prefix part, discussed in Section 2.4, "The Software Collection Prefix" , and the name and version number of the application that is a part of the Software Collection. These two parts of the Software Collection package name are separated by a dash ( - ), as in the following example: In this example, myorganization-ruby193 is the prefix, and foreman-1.1 is the name and version number of the application.

Commands:
myorganization-ruby193-foreman-1.1
Chapter 37. Converting a guided decision table to a spreadsheet decision table After you define a guided decision table in Business Central, you can convert the guided decision table to an XLS spreadsheet decision table file for offline reference and file sharing. The guided decision table must be an extended entry guided decision table in order to be converted. The conversion tool does not support limited entry guided decision tables. For more information about spreadsheet decision tables, see Designing a decision service using spreadsheet decision tables . Warning Guided decision tables and spreadsheet decision tables are different table formats that support different features. Any supported features that differ between the two decision table formats (Hit policy, for example) are modified or lost when you convert one decision table format to the other. Procedure In Business Central, navigate to the guided decision table asset that you want to convert and in the upper-right toolbar of the decision tables designer, click Convert to XLS : Figure 37.1. Convert an uploaded decision table After the conversion, the converted decision table is then available as a spreadsheet decision table asset in your project that you can download for offline reference.

Commands:
Chapter 3. Reviewing Automation execution environments with Automation content navigator As a content developer, you can review your automation execution environment with Automation content navigator and display the packages and collections included in the automation execution environments. Automation content navigator runs a playbook to extract and display the results. 3.1. Reviewing Automation execution environments from Automation content navigator You can review your Automation execution environments with the Automation content navigator text-based user interface. Prerequisites automation execution environments Procedure Review the automation execution environments included in your Automation content navigator configuration. USD ansible-navigator images Type the number of the automation execution environment you want to delve into for more details. You can review the packages and versions of each installed automation execution environment and the Ansible version any included collections. Optional: pass in the automation execution environment that you want to use. This becomes the primary and is the automation execution environment that Automation content navigator uses. USD ansible-navigator images --eei registry.example.com/example-enterprise-ee:latest Verification Review the automation execution environment output.

Commands:
ansible-navigator images
ansible-navigator images --eei registry.example.com/example-enterprise-ee:latest
20.18. Converting QEMU Arguments to Domain XML The virsh domxml-from-native command provides a way to convert an existing set of QEMU arguments into a Domain XML configuration file that can then be used by libvirt. Note that this command is intended to be used only to convert existing QEMU guests previously started from the command line, in order to enable them to be managed through libvirt. Therefore, the method described here should not be used to create new guests from scratch. New guests should be created using either virsh, virt-install , or virt-manager . Additional information can be found on the libvirt upstream website . Procedure 20.3. How to convert a QEMU guest to libvirt Start with a QEMU guest with a arguments file (file type *.args ), named demo.args in this example: To convert this file into a domain XML file so that the guest can be managed by libvirt, enter the following command. Remember to replace qemu-guest1 with the name of your guest virtual machine and demo.args with the filename of your QEMU args file. # virsh domxml-from-native qemu-guest1 demo.args This command turns the demo.args file into the following domain XML file: <domain type='qemu'> <uuid>00000000-0000-0000-0000-000000000000</uuid> <memory>219136</memory> <currentMemory>219136</currentMemory> <vcpu>1</vcpu> <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu</emulator> <disk type='block' device='disk'> <source dev='/dev/HostVG/QEMUGuest1'/> <target dev='hda' bus='ide'/> </disk> </devices> </domain> Figure 20.1. Guest virtual machine new configuration file

Commands:
cat demo.args LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb
<domain type='qemu'> <uuid>00000000-0000-0000-0000-000000000000</uuid> <memory>219136</memory> <currentMemory>219136</currentMemory> <vcpu>1</vcpu> <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu</emulator> <disk type='block' device='disk'> <source dev='/dev/HostVG/QEMUGuest1'/> <target dev='hda' bus='ide'/> </disk> </devices> </domain>
Chapter 11. Red Hat build of Kogito service properties configuration When a Red Hat build of Kogito microservice is deployed, a configMap resource is created for the application.properties configuration of the Red Hat build of Kogito microservice. The name of the configMap resource consists of the name of the Red Hat build of Kogito microservice and the suffix -properties , as shown in the following example: Example configMap resource generated during Red Hat build of Kogito microservice deployment kind: ConfigMap apiVersion: v1 metadata: name: kogito-travel-agency-properties data: application.properties : |- property1=value1 property2=value2 The application.properties data of the configMap resource is mounted in a volume to the container of the Red Hat build of Kogito microservice. Any runtime properties that you add to the application.properties section override the default application configuration properties of the Red Hat build of Kogito microservice. When the application.properties data of the configMap is changed, a rolling update modifies the deployment and configuration of the Red Hat build of Kogito microservice.

Commands:
kind: ConfigMap apiVersion: v1 metadata: name: kogito-travel-agency-properties data: application.properties : |- property1=value1 property2=value2
13.2. Consoles and Logging During the Installation The following sections describe how to access logs and an interactive shell during the installation. This is useful when troubleshooting problems, but should not be necessary in most cases. 13.2.1. Accessing Consoles The Red Hat Enterprise Linux installer uses the tmux terminal multiplexer to display and control several windows you can use in addition to the main interface. Each of these windows serves a different purpose - they display several different logs, which can be used to troubleshoot any issues during the installation, and one of the windows provides an interactive shell prompt with root privileges, unless this prompt was specifically disabled using a boot option or a Kickstart command. Note In general, there is no reason to leave the default graphical installation environment unless you need to diagnose an installation problem. The terminal multiplexer is running in virtual console 1. To switch from the graphical installation environment to tmux , press Ctrl + Alt + F1 . To go back to the main installation interface which runs in virtual console 6, press Ctrl + Alt + F6 . Note If you choose text mode installation, you will start in virtual console 1 ( tmux ), and switching to console 6 will open a shell prompt instead of a graphical interface. The console running tmux has 5 available windows; their contents are described in the table below, along with keyboard shortcuts used to access them. Note that the keyboard shortcuts are two-part: first press Ctrl + b , then release both keys, and press the number key for the window you want to use. You can also use Ctrl + b n and Ctrl + b p to switch to the or tmux window, respectively. Table 13.1. Available tmux Windows Shortcut Contents Ctrl + b 1 Main installation program window. Contains text-based prompts (during text mode installation or if you use VNC Direct Mode), and also some debugging information. Ctrl + b 2 Interactive shell prompt with root privileges. Ctrl + b 3 Installation log; displays messages stored in /tmp/anaconda.log . Ctrl + b 4 Storage log; displays messages related storage devices from kernel and system services, stored in /tmp/storage.log . Ctrl + b 5 Program log; displays messages from other system utilities, stored in /tmp/program.log . In addition to displaying diagnostic information in tmux windows, Anaconda also generates several log files, which can be transferred from the installation system. These log files are described in Table 14.1, "Log Files Generated During the Installation" , and directions for transferring them from the installation system are available in Chapter 14, Troubleshooting Installation on IBM Power Systems . 13.2.2. Saving Screenshots You can press Shift + Print Screen at any time during the graphical installation to capture the current screen. These screenshots are saved to /tmp/anaconda-screenshots/ . Additionally, you can use the autostep --autoscreenshot command in a Kickstart file to capture and save each step of the installation automatically. See Section 27.3.1, "Kickstart Commands and Options" for details.

Commands:
12.3. Assigning a PCI Device with virt-install To use virt-install to assign a PCI device, use the --host-device parameter. Procedure 12.5. Assigning a PCI device to a virtual machine with virt-install Identify the device Identify the PCI device designated for device assignment to the guest virtual machine. The virsh nodedev-list command lists all devices attached to the system, and identifies each PCI device with a string. To limit output to only PCI devices, run the following command: Record the PCI device number; the number is needed in other steps. Information on the domain, bus and function are available from output of the virsh nodedev-dumpxml command: Add the device Use the PCI identifier output from the virsh nodedev command as the value for the --host-device parameter. Complete the installation Complete the guest installation. The PCI device should be attached to the guest.

Commands:
lspci | grep Ethernet 00:19.0 Ethernet controller: Intel Corporation 82567LM-2 Gigabit Network Connection 01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 01:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
virsh nodedev-list --cap pci pci_0000_00_00_0 pci_0000_00_01_0 pci_0000_00_03_0 pci_0000_00_07_0 pci_0000_00_10_0 pci_0000_00_10_1 pci_0000_00_14_0 pci_0000_00_14_1 pci_0000_00_14_2 pci_0000_00_14_3 pci_0000_00_19_0 pci_0000_00_1a_0 pci_0000_00_1a_1 pci_0000_00_1a_2 pci_0000_00_1a_7 pci_0000_00_1b_0 pci_0000_00_1c_0 pci_0000_00_1c_1 pci_0000_00_1c_4 pci_0000_00_1d_0 pci_0000_00_1d_1 pci_0000_00_1d_2 pci_0000_00_1d_7 pci_0000_00_1e_0 pci_0000_00_1f_0 pci_0000_00_1f_2 pci_0000_00_1f_3 pci_0000_01_00_0 pci_0000_01_00_1 pci_0000_02_00_0 pci_0000_02_00_1 pci_0000_06_00_0 pci_0000_07_02_0 pci_0000_07_03_0
virsh nodedev-dumpxml pci_0000_01_00_0 <device> <name>pci_0000_01_00_0</name> <parent>pci_0000_00_01_0</parent> <driver> <name>igb</name> </driver> <capability type='pci'> <domain>0</domain> <bus>1</bus> <slot>0</slot> <function>0</function> <product id='0x10c9'>82576 Gigabit Network Connection</product> <vendor id='0x8086'>Intel Corporation</vendor> <capability type='virt_functions'> </capability> </capability> </device>
virt-install --name=guest1-rhel6-64 --disk path=/var/lib/libvirt/images/guest1-rhel6-64.img,size=8 --nonsparse --graphics spice --vcpus=2 --ram=2048 --location=http://example1.com/installation_tree/RHEL6.1-Server-x86_64/os --nonetworks --os-type=linux --os-variant=rhel6 --host-device= pci_0000_01_00_0