A process is a running instance of a launched, executable program. A process consists of:
- an address space of allocated memory,
- security properties including ownership credentials and privileges,
- one or more execution threads of program code, and
- the process state.
The environment of a process includes:
- local and global variables,
- a current scheduling context, and
- allocated system resources, such as file descriptors and network ports.
An existing (parent) process duplicates its own address space (fork) to create a new (child) process structure. Every new process is assigned a unique process ID (PID) for tracking and security. The PID and the parent's process ID (PPID) are elements of the new process environment. Any process may create a child process. All processes are descendants of the first system process, which is systemd(1) on a Red Hat Enterprise Linux 7 system.
Through the fork routine, a child process inherits security identities, previous and current file descriptors, port and resource privileges, environment variables, and program code. A child process may then exec its own program code. Normally, a parent process sleeps while the child process runs, setting a request (wait) to be signaled when the child completes. Upon exit, the child process has already closed or discarded its resources and environment; the remainder is referred to as a zombie. The parent, signaled awake when the child exited, cleans the remaining structure, then continues with its own program code execution.
In a multitasking operating system, each CPU (or CPU core) can be working on one process at a single point in time. As a process runs, its immediate requirements for CPU time and resource allocation change. Processes are assigned a state, which changes as circumstances require.
The Linux process states are illustrated in the previous diagram and described in the following table.
| Name |
Flag |
Kernel-defined state name and description |
| Running |
R
|
TASK_RUNNING: The process is either executing on a CPU or waiting to run.
Process can be executing user routines or kernel routines (system calls),
or be queued and ready when in the Running (or
Runnable) state.
|
| Sleeping |
S
|
TASK_INTERRUPTIBLE: The process is waiting for some condition:
a hardware request, system resource access, or signal.
When an event or signal satisfies the condition, the process
returns to Running.
|
D
|
TASK_UNINTERRUPTIBLE: This process is also Sleeping, but
unlike S state, will not respond to delivered signals.
Used only under specific conditions in which process interruption
may cause an unpredictable device state.
|
K
|
TASK_KILLABLE: Identical to the uninterruptible D state, but modified to
allow the waiting task to respond to a signal to be killed (exited completely).
Utilities frequently display Killable processes as D state.
|
| Stopped |
T
|
TASK_STOPPED: The process has been Stopped (suspended),
usually by being signaled by a user or another process.
The process can be continued (resumed) by another signal
to return to Running.
|
T
|
TASK_TRACED: A process that is being debugged is also temporarily
Stopped
and shares the same T state flag.
|
| Zombie |
Z
|
EXIT_ZOMBIE: A child process signals its parent as it exits.
All resources except for the process identity (PID) are released.
|
X
|
EXIT_DEAD: When the parent cleans up (reaps)
the remaining child process structure, the process is now released completely.
This state will never be observed in process-listing utilities.
|
Please see the following page: https://access.redhat.com/solutions/238533, if you need to update a Red Hat Enterprise Linux system, but need to ensure at the same time that the system isn't upgraded to a new minor release (e.g. from version 7.3 to version 7.4).
The trick is to use the "releasever" option with the yum commmand. For example, if you have a Red Hat Enterprise Linux system running version 7.3 (check with "cat /etc/redhat-release), and you need to keep it at this version (e.g. for application specific reasons), then run the following command to only update the system pacakages relevant to version 7.3:
# yum --releasever=7.3 update
Once the update has been completed, check file /etc/redhat-release to ensure the system is still at version 7.3, and has not been upgraded to version 7.4.
And don't forget to reboot the system after doing updates. The following command will indicate if the command needs to be rebooted, to ensure that all installed updates are properly activated:
# needs-restarting -r
If the needs-restarting command is not avaialable on your system, then please ensure to install RPM yum-utils:
# yum -y install yum-utils
The general procedure for resizing a swap space is as follows (assuming the swap space is set up as a logical volume within the root volume group called vg_root), for example to resize a swap space to 8 GB:
# swapoff -v /dev/mapper/vg_root-lv_swap
# lvm lvresize /dev/mapper/vg_root-lv_swap -L 8G
# mkswap /dev/mapper/vg_root-lv_swap
# swapon -va
There are 2 easy ways to read PDF files in Gnone (the default desktop for Red Hat Enterprise Linux): Use Firefox or Evince.
Evince is the Gnome document viewer, and can be easily opened as follows:
# evince /usr/share/doc/libtasn1-4.10/libtasn1.pdf
You can also use Firefox. Firefox has built-in PDF support. You can open it as follows:
# firefox /usr/share/doc/libtasn1-4.10/libtasn1.pdf
Here's how to register and un-register a Red Hat system through subscription-manager. You'll need to do this, for example, if you wish to do operating system updates on a Red Hat system.
First, here's how to unregister a system. This might come in handy if you do not have enough subscriptions in your Red Hat account, and temporarily want to move a valid subscription over to another system):
# subscription-manager unregister
System has been unregistered.
And here's how you register:
# subscription-manager register
Registering to: subscription.rhsm.redhat.com:443/subscription
Username: [type your Red Hat username here]
Password: [type your Red Hat password here]
The system has been registered with ID: 3db39bee-bd48-46e8-9abc-9ba9
If you have issues registering a server, try removing all Red Hat subscription information first, and then register again, using the "auto-attach" option:
# subscription-manager clean
All local data removed
# subscription-manager list
+-------------------------------------------+
Installed Product Status
+-------------------------------------------+
Product Name: Red Hat Enterprise Linux Server
Product ID: 69
Version: 7.4
Arch: x86_64
Status: Unknown
Status Details:
Starts:
Ends:
# subscription-manager register --auto-attach
Registering to: subscription.rhsm.redhat.com:443/subscription
Username: [type your Red Hat username here]
Password: [type your Red Hat password here]
The system has been registered with ID: 3db39bee-bd48-46e8-9abc-9ba9
Installed Product Current Status:
Product Name: Red Hat Enterprise Linux Server
Status: Subscribed
# subscription-manager list
+-------------------------------------------+
Installed Product Status
+-------------------------------------------+
Product Name: Red Hat Enterprise Linux Server
Product ID: 69
Version: 7.4
Arch: x86_64
Status: Subscribed
Status Details:
Starts: 12/27/2017
Ends: 12/26/2020
If you wish to use a specific Red Hat subscription, then you may first check for the available Red Hat subscriptions, by running:
# subscription-manager list --available --all
In the output of the command above, you will see, if any subscriptions are available, a Pool ID. You can use that Pool ID to attach a specific subscription to the system, for example, by running:
# subscription-manager attach pool=8a85f98c6267d2d90162734a700467b2
The following procedure describes how to set up a bonded network interface on Red Hat Enterprise Linux. It assumes that you already have a working single network interface, and wish to now move the system to a bonded network interface set-up, to allow for network redundancy, for example by connecting two separate network interfaces, preferably on two different network cards in the server, to two different network switches. This provides both redundancy, should a network card in the server fail, and also if a network switch would fail.
First, log in as user root on the console of the server, as we are going to change the current network configuration to a bonded network configuration, and while doing so, the system will lose network connectivity temporarilty, so it is best to work from the console.
In this procedure, We'll be using network interfaces em1 and p3p1, on two different cards, to get card redundancy (just in case one of the
network cards will fail).
Let's assume that IP address 172.29.126.213 is currently configured on network interface em1. You can verify that, by running:
# ip a s
Also, we'll need to verify, using the ethtool command, that there is indeed a good link status on both the em1 and p3p1 network interfaces:
# ethtool em1
# ethtool p3p1
Run, to list the bonding module info (should be enabled by default already, so this is just to verify):
# modinfo bonding
Create copies of the current network files, just for safe-keeping:
# cd /etc/sysconfig/network-scripts
# cp ifcfg-em1 /tmp
# cp ifcfg-p3p1 /tmp
Now, create a new file ifcfg-bond0 in /etc/sysconfig/network-scripts. We'll configure the IP address of the system (the one that was configured previously on network interface em1) on a new bonded network interface, called bond0. Make sure to update the file with the correct IP address, gateway and network mask for your environment:
# cat ifcfg-bond0
DEVICE=bond0
TYPE=Bond
NAME=bond0
BONDING_MASTER=yes
BOOTPROTO=none
ONBOOT=yes
IPADDR=172.29.126.213
NETMASK=255.255.255.0
GATEWAY=172.29.126.1
BONDING_OPTS="mode=5 miimon=100"
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
The next thing to do is to create two more files, one for each network interfaces that will be the slaves of the bonded network interface. In our example, that will be em1 and p3p1.
Create file /etc/sysconfig/network-scripts/ifcfg-em1 (be sure to update the file to your environment, for example, use the correct UUID. You may find that in the copies you've made of the previous network interface files. In this file, you'll also specify that the bond0 interface is now the master.
# cat ifcfg-em1
TYPE=Ethernet
BOOTPROTO=none
NAME=em1
UUID=cab24cdf-793e-4aa7-a093-50bf013910db
DEVICE=em1
ONBOOT=yes
MASTER=bond0
SLAVE=yes
Create file ifcfg-p3p1:
# cat ifcfg-p3p1
TYPE=Ethernet
BOOTPROTO=none
NAME=p3p1
UUID=5017c829-2a57-4626-8c0b-65e807326dc0
DEVICE=p3p1
ONBOOT=yes
MASTER=bond0
SLAVE=yes
Now, we're ready to start using the new bonded network interface. Restart the network service:
# systemctl restart network.service
Run the ip command to check the current network config:
# ip a s
The IP address should now be configured on the bond0 interface.
Ping the default gateway, to test if your bonded network interface can reach the switch. In our example, the default gateway is set to 172.29.126.1:
# ping 172.29.126.1
This should work. If not, re-trace the steps you've done so far, or work with your network team to identify the issue.
Check that both interfaces of the bonded interface are up, and what the current active network interface is. You can do this by looking at file /proc/net/bonding/bond0. In this file you can see what the currently active slave is, and if all slaves of the bonded network interface are up. For example:
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: transmit load balancing
Primary Slave: None
Currently Active Slave: p3p1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: p3p1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0a:f7:ce:26:30
Slave queue ID: 0
Slave Interface: em1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0a:f7:bd:b7:9e
Slave queue ID: 0
In the example above, the active network interface is p3p1. Let's bring it down, to see if it fails over to network interface em1. You can bring down a network interface using the ifdown command:
# ifdown p3p1
Device 'p3p1' successfully disconnected.
Again, look at the /proc/net/bonding/bond0 file. You can now see that the active network interface has changed to em1, and that network interface p3p1 is no longer listed in the file (because it is down):
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: transmit load balancing
Primary Slave: None
Currently Active Slave: em1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: em1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0a:f7:bd:b7:9e
Slave queue ID: 0
Now ping the default gateway again, and make sure it still works (now that we're using network interface em1 instead of network interface p3p1).
Then bring the p3p1 interface back up, using the ifup command:
# ifup p3p1
And check the bonding status again:
# cat /proc/net/bonding/bond0
It should show that the active network interface is still on em1, it will not fail back to network interface p3p1 (After all, why would it?! Network interface em1 works just fine).
Now repeat the same test, by bringing down network interface em1, ping the default gateway again, and check the bonding status, and bring em1 back up:
# ifdown em1
# cat /proc/net/bonding/bond0
# ping 172.29.126.1
# ifup em1
# cat /proc/net/bonding/bond0
# ping 172.29.126.1
If this all works fine, then you're all set.
This next piece describes how to configure the storage multi-pathing software on a Red Hat Enterprise Linux 7 system. This is a required to install if you're using SAN storage and multiple paths are available to the storage (which is usually the case).
First, check if all required software is installed. It generally is, but it's good to check:
# yum -y install device-mapper-multipath
Next, check if the multipath daemon is running:
# service multipathd status
If it is, stop it:
# service multipathd stop
Configure file /etc/multipath.conf, which is the configuration file for the multipath daemon:
# mpathconf --enable --with_multipathd y
This will create a default /etc/multipath.conf file, which will work quite well often, without any further configuration needed.
Then start the multipath daemon:
# service multipathd start
Redirecting to /bin/systemctl start multipathd.service
You can now use the lsblk command to view the disks that are configured on the system.
# lsblk
This command should show that there have been mpathX devices created, which are the multipath devices managed by the multipath daemon, and you can now start using these mpathX disk devices as storage on the Red Hat system. Another way to check the mpath disk devices available on the system, is by looking at the /dev/mapper directory:
# ls -als /dev/mapper/mpath*
If you have a clustered environment, where SAN storage devices are zoned and allocated to multiple systems, you may want to ensure that all the nodes in the cluster are using the same naming for the mpathX devices. That makes it easier to recognize which disk is which on each system.
To ensure that all the nodes in the cluster use the same naming, first run a "cat /etc/multipath/bindings" command on all nodes, and identify which disks are shared on all nodes, and what the current naming of the mpathX devices on each system looks like. It may well be that the naming of the mpathX devices is already consistent on all cluster nodes.
If it is not, however, then copy file /etc/multipath/bindings from one server to all other cluster nodes. Be careful when doing this, especially when one or more servers in a cluster have more SAN storage allocated than others. Be sure that only those entries in /etc/multipath/bindings are copied over to all cluster nodes, where the entries represent shared storage on all cluster nodes. Any SAN storage allocated to just one server will show up in the /etc/multipath/bindings file for that server only, and it should not be copied over to other servers.
Once the file is correct on all cluster nodes. Restart the multipath daemon on each cluster node:
# service multipathd stop
# multipath -F
# service multipathd start
If you now do a "ls" in /dev/mapper on each cluster node, you'll see the same mpath names on all cluster nodes.
Once this is complete, make sure that the multipath daemon is started at system boot time as well:
# systemctl enable multipathd
There are two commands that can be used to add a route on an AIX system.
The first one is route, and can be used to temporarily add a route to an AIX system. Meaning, if the system is rebooted, after the route has been added, the route will be lost again after the reboot.
The second command is chdev -l inet0 that can be used to permanently add a route on an AIX system. When this command is used, the route will persist during reboots, as this command writes to information of the route in to the ODM of AIX.
Let's say you have a need to add a route on a system to network 10.0.0.0. And that network uses a netmask of 255.255.255.0 (or "24" for the short mask notation). Finally, the gateway that can be used to access this network is 192.168.0.1. Obviously, please adjust this to your own situation.
To temporarily add a route on a system for this network, use the following route command:
# route add -net 10.0.0.0 -netmask 255.255.255.0 192.168.0.1
After running this command, you can use the
netstat -nr command to confirm that the route indeed has been set up:
# netstat -nr | grep 192.168.0.1
172.30.224/24 192.168.0.1 UG 0 0 en1 - -
To remove that route again, simply change the route command from "add" to "delete":
# route delete -net 10.0.0.0 -netmask 255.255.255.0 192.168.0.1
Again, confirm with the
netstat -nr command that the route indeed has been removed.
Now, as mentioned earlier, the route command will only temporarily (until the next reboot) add a route on the AIX system. To make things permanent, use the chdev command. This command takes the following form:
chdev -l inet0 -a route=net,-netmask,[your-netmask-goes-here],-static,[your-network-address-goes-here],[your-gateway-goes-here]
For example:
# chdev -l inet0 -a route=net,-netmask,255.255.255.0,-static,10.0.0.0,
192.168.0.1
inet0 changed
This time, again, you can confirm with the
netstat -nr command that the route has been set up. But now you can also confirm that the route has been added to the ODM, by using this command:
# lsattr -El inet0 -a route | grep 192.168.0.1
route net,-netmask,255.255.255.0,-static,10.0.0.0,192.168.0.1 Route True
At this point, you can reboot the system, and you'll notice that the route is still there, by repeating the
netstat -nr and
lsattr -El inet0 commands.
To remove this permanent route from the AIX system, simply change the chdev command above from "route" to "delroute":
# chdev -l inet0 -a delroute=net,-netmask,255.255.255.0,-static,10.0.0.0,
192.168.0.1
inet0 changed
Finally, again confirm using the
netstat -nr and
lsattr -El inet0 commands that the route indeed has been removed.
This article describes how to add a new volume group to an existing resource group of an active PowerHA cluster.
The first step is to add the storage to both of the nodes of the PowerHA cluster. In the case of SAN storage, please ensure that your storage administrator adds the storage to both nodes of the cluster. Then discover the newly added storage by running the cfgmgr command on one of the nodes:
# cfgmgr
Set a PVID on all the new disks that have been discovered. For example, for disk hdisk77, run:
# chdev -l hdisk77 -a pv=yes
Repeat this command for any of the new disks.
Next, log in to the other node, and run the cfgmgr command on that node as well, so the disks will be discovered on the other node as well. And when you run "lspv" on the second node after running cfgmgr, you'll notice that the PVID is already set for all the discovered disks (it was set on the first node).
On both nodes, make sure that the disk attributes are set correctly. Now, this may differ for the type of storage used (so please make sure to check your storage vendor's recommendations on this topic), but a good starting point is (for example, for disk hdisk4):
# chdev -l hdisk4 -a max_transfer=0x100000 -a queue_depth=32 -a reserve_policy=no_reserve -a algorithm=round_robin
For clustered nodes, it's important that the reserve_policy is set to no_reserve.
A note about the max_transfer attribute: This value should be set to the same value as the max_xfer_size attribute of the fiber adapter. By default attribute max_transfer is set to 0x40000, which is usually lower than the max_xfer_size attribute on the fiber adapter, which results in a smaller buffer size memory being used. To check the max_xfer_size attribute on the fiber adapter, run (for example for adapter fcs0):
# lsattr -El fcs0 -a max_xfer_size
Also please make sure to set the disk attributes for all the new disks on both nodes. These attributes are stored in the ODM of the AIX system locally, and don't automatically transfer over to other nodes of the cluster, so you'll have to set these attributes for all new disks on all cluster nodes.
The next step is to create the new volume group(s). The first thing that we'll need to know is a common majar number that is available on both nodes of a cluster. For that purpose, run the following command on all cluster nodes, which lists the available major numbers:
# lvlstmajor
Choose a major number available on all cluster nodes. For the purpose of this article, let's assume major number 57 is available.
For PowerHA, a new volume group should be configured as concurrent-capable (configured by the -C option of the mkvg command). Also, The quorum should be disabled (by using -Qn), and the auto-varyon should be disabled as well (by using the -n option) as PowerHA will varyon the volume group for us. Finally, the major number should be set (in the example below: -V 57).
As such, run the following mkvg command to create the volume group (Note: please adjust the volume group name, the major number and disk names according to your situation and preference):
# mkvg -v 57 -S -n -Qn -y fs01vg hdisk38 hdisk42 hdisk45
Note: run this command on only one of the cluster nodes, and continue working on this cluster node for now for the next steps.
Next, create a logical volume (adjust per your situation and preference):
# mklv -y fs01lv -t jfs2 -u 1 -x 1278 hdisk38
This command will create logical volume fs01lv for the purpose of using it for a JFS2 type file system, with an upper bound of 1 (just use 1 disk), and allocate 1278 partitions on disk hdisk38.
Then create a file system on the previously defined logical volume:
# crfs -v jfs2 -d fs01lv -a logname=INLINE -a options=noatime -m /fs01 -A no
This command will create file system /fs01 on top of logical volume fs01lv, and will use an inline log (recommended for optimal performance), will not record access times (options=noatime) to avoid unneccessary writes to the file system, and will tell AIX not to automatically mount the file system at system start (-A no), as PowerHA will mount the file system instead.
At this point, the volume group, logical volume and file system have been created. You can create additional volume groups, logical volumes and file systems as it pertains to your situation. Once done, ensure that the volume group is varied off, for example for volume group fs01vg:
# varyoffvg fs01vg
Should the varyoff command fail at this point, then please check if the file system(s) is/are still mounted, and un-mount them before running the varyoffvg command.
Now run "lspv" on both nodes of the cluster, and look at the PVIDs listed. Pick one of the disks on which you configured the volume group on the first node, and take that disk's PVID, for example 00fac78651b28b53. On the other node, run the importvg command to import the volume group (which also imports the information about any logical volumes and file systems configured in that volume group), using the PVID of one of the disks, and the major number previously defined, for example:
# importvg -n -V 57 -y fs01vg 00fac78651b28b53
Repeat this for any additional volume groups in your situation. Do make sure to select the correct PVID of one of the disks in the volume group on the first node when importing this volume group on the second node, as you'll want to make sure both nodes of a PowerHA cluster use the same volume group names.
At this time, the storage is properly configured on both nodes, and it is time to add the volume group(s) to the PowerHA resource group.
First, verify that the cluster is in a good state by running:
# smitty hacmp
problem determination tools
powerha verification
verify powerha configuration
Once confirmed, allow PowerHA to discover the new disks in the cluster:
# smitty cm_discover_nw_interfaces_and_disks
Now add the volume group(s) to the resource group of the cluster:
# smitty hacmp
cluster applications and resources
resource groups
change/show resources and attributes for a resource group
Select your resource group, and add the volume group(s) to the "Volume Groups" entry.
Next, sync the cluster, which should bring the volume group(s) online:
# smitty hacmp
cluster applications and resources
verify and synchronize cluster configuration
Once this is complete, you should be able to see the new volume group(s) online, by running:
# lsvg -o
And you should be able to see that any new file systems have been mounted by PowerHA:
# df
Not required, but good practice, is to now schedule a failover test for your PowerHA cluster, to ensure everything is still working as it should, in case of a fail-over scenario.
PowerHA version 7 (starting with version 7.1.3) includes a new feature that allows you to generate an HTML report that includes a lot of very useful information of your PowerHA cluster. There are no external requirements, and it is included is the base PowerHA product.
The command needed to generate the report is clmgr. For example:
# clmgr view report cluster TYPE=html FILE=/tmp/powerha.report
You may also include a company logo and name, for example by running:
# clmgr view report cluster TYPE=html FILE=/tmp/powerha.report COMPANY_LOGO="mylogo.jpg" COMPANY_NAME="MY COMPANY"
Tip: You may schedule this command through cron to get a regular up to date version.
This HTML report is officially only supported on Internet Explorer and Firefox, although other browsers might work just fine.
Number of results found: 469.
Displaying results: 51 - 60.
