Tag Archives: hpux

Logs under /var/stm/logs/os in HPUX

Your /var mount point is getting full? You need to check /var/stm/logs/os directory for old logs. Lots of space can be saved by zipping or purging them.

Ever wondered why /var/stm/logs/os is taking up huge space in /var mount point of HPUX? In this post, we will see details about logs under this directory and how to handle them.

Most of the time you get /var getting full alerts from your monitoring system or you observe /var is filling up. This is normal behavior since most of the logs reside in /var and if some logs are growing fast they cause /var filling up fast. As a first troubleshooting step, you need to check huge size files and directories in /var.

Many times you see one of the culprit is /var/stm/logs/os directory. If you see inside this directory you will see something like below :

# ls -lrt /var/stm/logs/os
total 6986016
-rw-r--r--   1 root       root        512656 Apr 10  2008 log1.raw
-rw-r--r--   1 root       root        512656 Apr 10  2008 log2.raw
-rw-r--r--   1 root       root        512656 Apr 10  2008 log3.raw
-rw-r--r--   1 root       root        512656 Apr 11  2008 log4.raw
-rw-r--r--   1 root       root        512656 Apr 11  2008 log5.raw
-rw-r--r--   1 root       root        512656 Apr 11  2008 log6.raw
-rw-r--r--   1 root       root        512656 Apr 11  2008 log7.raw
----- ouput clipped -----

There are lots of raw log files taking up huge space collectively.

What are these logs under /var/stm/logs/os :

Your next question will be what are these files? what is the purpose of these files on the server?

These are raw files that are being logged and used by STM i.e. support tool manager. Those are logs collected by STM which has information about your hardware issues. By the above output, you can see those are rotated when one log file crosses a certain file size. While rotating they are sequentially numbered. This numbering makes it easy when it comes to managing those logs.

How to read these logs :

You can read these logs using log viewer by STM. Goto CSTM console using command cstm

# /usr/sbin/cstm
Running Command File (https://z5.kerneltalks.com/usr/sbin/stm/ui/config/.stmrc).

-- Information --
Support Tools Manager

Version A.59.05

Product Number B4708AA

(C) Copyright Hewlett Packard Co. 1995-2007
All Rights Reserved

Use of this program is subject to the licensing restrictions described
in "Help-->On Version".  HP shall not be liable for any damages resulting
from misuse or unauthorized use of this program.

cstm>

Then run ru and select logtool utility.

cstm>ru
-- Run Utility --
Select Utility
    1 MOutil
    2 logtool
Enter selection or cancel to quit : 2

-- Logtool Utility --
To View a Summary of Events in a Raw Log

  1. Select a raw (unformatted) log file.  (File Menu -> "Select Raw")
     The current log file ends in ".cur", e.g. "log1.raw.cur".
     You do not have to switch logs.

  2. View the summary of the selected log file. (View Menu -> "Raw Summary")

To Format a Raw Log

  1. Set the format filter for the types of entries you want to see.
     (Filters Menu -> "Format").  To see all entries, skip this step.

  2. Format the raw log file. (File Menu -> "Format Raw")

  3. Display the formatted file. (View Menu -> "Formatted Log")

  4. To further narrow the entries displayed, set a display filter.
     (Filters Menu -> "Display" -> "Formatted")

For more information, use the on-line help (Help Menu -> "General help").

Logtool Utility>

With give information on console you can view, format raw log files.

Should I purge or zip /var/stm/logs/os logs ?

Now you know what are these files and you observe there are too many of them which are too old to keep. In such a scenario, you have got two options:

  • Zip them: For few months old files. Maybe 1-2 months old. How to zip files.
  • Purge them: For very old logs like 6 or more months old.

Make a note that those logs are read by STM as well so if you purge or zip them, STM won’t be able to use them.

So be sure you check logs using logtool utility explained above and decide to purge, zip, or keep it. Normally, if you are not facing any hardware issues with the server currently then you should zip/purge according to the time frame I suggested above.

# ls -lrt /var/stm/logs/os
total 2463008
-rw-r--r--   1 root       root         65910 Apr 10  2008 log1.raw.gz
-rw-r--r--   1 root       root         57168 Apr 10  2008 log2.raw.gz
-rw-r--r--   1 root       root         53727 Apr 10  2008 log3.raw.gz
-rw-r--r--   1 root       root         40526 Apr 11  2008 log4.raw.gz
-rw-r--r--   1 root       root         39541 Apr 11  2008 log5.raw.gz
-rw-r--r--   1 root       root         37050 Apr 11  2008 log6.raw.gz
-rw-r--r--   1 root       root         37624 Apr 11  2008 log7.raw.gz

Match above output with previous and see how file size decreased after zipping which in turns saved my /var space.

Zipping of purging these logs will greatly free up space under /var mount point. This is one of the directories which we normally miss or ignore while cleaning up the mount point.

Alternatively, you can even configure logrotate utility which will take care of this zipping and purging of files automatically without human intervention.

Adding new storage LUN to integrity virtual machine (iVM) in HPUX

Step by step procedure to add storage LUNs to integrity virtual machine on HPUX host. Further, learn to use those LUNs in LVM of the guest servers.

Steps to add new LUN into integrity virtual machine (iVM) in HPUX and use it within existing VG or create a new VG on it. In this process, storage luns are always presented to the physical host server. from host, they are attached to the virtual guest server running on it.

Step 1

Identify new LUN on the HP iVM host server. When new LUN is presented to iVM, run ioscan command to scan new disks. Post ioscan, run insf command to make sure all available hardware has its related files created in the kernel.

# ioscan -fnCdisk
# insf -e

Now your new LUN is identified in the kernel. Match lun id in storage utility (syminq in case of EMC storage, evainfo in case of HP EVA storage etc) and get related disk number. We are using agile naming convention here so lets take /dev/rdisk/disk10/dev/rdisk/disk11 are new identified disks.

Step 2

Make disks LVM ready by using pvcreate.

# pvcreate /dev/rdisk/disk10
Physical volume "/dev/rdisk/disk10" has been successfully created.

# pvcreate /dev/rdisk/disk11
Physical volume "/dev/rdisk/disk11" has been successfully created.

Step 3

Attach these disks to iVM (guest) which is running on the host. Assume vmserver1 is our iVM here.

# hpvmmodify -P vmserver1 -a disk:avio_stor::disk:/dev/rdisk/disk10
# hpvmmodify -P vmserver1 -a disk:avio_stor::disk:/dev/rdisk/disk11

Step 4

Once the above commands are successful, disks are attached to iVM and need to scan in the guest. Login to iVM server and scan the new disks the same way we did in steps 1 and 2 on the host. Let’s say those disks are identified as /dev/rdisk/disk2/dev/rdisk/disk3 on the guest server. Observe those are identified as Virtual disk on VM.

disk 6 0/0/0/0.2.0 sdisk CLAIMED DEVICE HP Virtual Disk
/dev/dsk/c0t2d0 /dev/rdsk/c0t2d0

disk 8 0/0/0/0.3.0 sdisk CLAIMED DEVICE HP Virtual Disk
/dev/dsk/c0t3d0 /dev/rdsk/c0t3d0

Step 5

Complete LVM tasks on these disks to use space in the mount point.
To create a new VG named vg01

# mkdir /dev/vg01
# mknod /dev/vg01/group c 64 0x010000
# vgcreate -s 64 -p 60 -e 12500 vg01 /dev/disk/disk2 /dev/disk/disk3
Volume group "/dev/vg01" has been successfully created.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf
# lvcreate -L 200 /dev/vg01
Logical volume "/dev/vg01/lvol1" has been successfully created with
character device "/dev/vg01/rlvol1".
# newfs -F vxfs -o largefiles /dev/vg01/rlvol1
 version 7 layout
 204800 sectors, 204800 blocks of size 1024, log size 1024 blocks
 largefiles supported
# mkdir /data
# mount /dev/vg01/lvol1 /data

To extend current existing VG named vg02 & mount point /data1 within it

# vgextend vg02 /dev/disk/disk2 /dev/disk/disk3
Volume group "vg02" has been successfully extended.
Volume Group configuration for /dev/vg02 has been saved in /etc/lvmconf/vg02.conf
# lvextend -L 512 /dev/vg02/lvol1
Logical volume "/dev/vg02/lvol1" has been successfully extended.
Volume Group configuration for /dev/vg02 has been saved in /etc/lvmconf/vg02.conf
# fsadm -F vxfs -b 524288 /data1
vxfs fsadm: V-3-23585: /dev/vg02/rlvol1 is currently 7731200 sectors - size will be increased

HPUX Patch naming conventions

HP releases the HPUX patch twice a year. Few break-fix patches releases as on need basis. Here are naming conventions being followed by HP.

HP releases OS patches for HPUX every 6 months i.e. twice a year. For smaller HPUX patch which are releases as on need basis, HP follows below naming conventions

Patch name format is PHxx_yyyy

Where,

xx = area of patch
CO: General HPUX commands
KL: Kernel patches
NE: Network-specific patch
SS: all other subsystem patches

yyyy = unique number

From patch name, you will be able to guess area of its impact so that you can plan your activities accordingly. If the patch requires a reboot or not can be determined while downloading the patch from the HP portal itself or even by running swinstall command with -p (preview) argument.

HP patches are available on http://software.hp.com/ which will redirect you to HP software depot home. HP passport login required to download patches or software from software depots.

Run levels in HPUX at a glance

Learn the list of different run levels in HPUX and their roles. Also, see how to check the current run level in which the system is running.

A run level is the state of a system depending on which system services will spawn. Normally lower run levels are having fewer services available for the user and mainly used for administrative purposes. Higher levels have more services available and targets end user’s use. In HPUX highest run levels like 5 and 6 are kept reserved for future purposes. We will see the list of run levels and their offerings in the following article.

Current run level in HPUX can be identified using the below command :

# who -r
   .       run-level 3  Jan 19 21:14    3    0    S

The output fields of the above commands are as below:
1. A dot . indicates that the terminal has seen activity in the last minute and is therefore its. i.e. current.
2. Current run-level
3. Timestamp
4. The current state of init
5. The number of times that state has been previously entered
6. The previous state

Read also: Different usage of ‘who’ command.

List of run levels in HPUX

0 indicates shutdown state
S indicates single user mode booted to local console only with root FC (RO) mounted
s indicates the same as S only current terminal acts as system console.
1 indicates the single-user mode with local FS (RW) mounted
2 indicates multi-user state with CDE launched
3 indicates the same as 2 but with NFS
4 indicates GUI (here VUE started instead of CDE)
5,6 indicates reserved to state and not yet defined in kernel code.