Category Archives: System services

How to configure JBOSS EAP 7 as a service in SUSE Linux

Step by step procedure to configure JBOSS EAP as service in SUSE Linux

JBOSS EAP as service

One of the major requirements for Jboss’s basic installations is to configure Jboss as a service in Linux. It’s pretty easy to configure it in RedHat and related families but when it comes to SUSE it pretty difficult since few functions of RedHat family don’t work in Suse. And with default ZIP installation we do not get the SUSE startup file as well which is readily available for RedHat.

We are considering Jboss EAP 7.2 on Suse 12 for this article.

RedHat has a pretty simple tutorial here which is not going to work on SUSE. So I will walk you through steps to get your Jboss eap working as service in SUSE Linux.


Pre-requisite

  • Make sure you have java installed on the server
  • Make sure JBoss user exists on the server which is defined in jboss-eap.conf file by parameter JBOSS_USER. Default user is jboss-eap
  • For default standalone configurations, INSTALL_PATH/standalone/ should be owned by JBOSS_USER
  • Make changes in init script template to match it with SUSE system as defined in below paragraph

Modification in script

You need to edit default init script INSTALL_PATH/bin/init.d/jboss-eap-rhel.sh to make it compatible with Suse.

  • Replace /etc/init.d/functions with /etc/rc.status
  • Replace success with rc_status -v

With JBoss zip install, you will have init script jboss-eap-rhel.sh located under INSTALL_PATH/bin/init.d This is init script which won’t be useful in latest Suse versions since they follow LSB format. So we need to make it work with LSB and here is how to do it.

Copy service configuration file and service init script from the installation directory to respective system directories –

root@kerneltalks # cp INSTALL_PATH/bin/init.d/jboss-eap.conf /etc/default
root@kerneltalks # cp INSTALL_PATH/bin/init.d/jboss-eap-rhel.sh /etc/init.d/jboss-eap
root@kerneltalks # chmod +x /etc/init.d/jboss-eap

Please note that while coping over file we trimmed rhel from its name since it does not make sense to keep that name on the SUSE system! It will also alter the next command as well.


Adding it as a service

root@kerneltalks # chkconfig --add jboss-eap

Till this point, its the same process as RedHat mentioned in its tutorial. Now, if you try to start service it won’t. It will throw below error :

root@kerneltalks # service jboss-eap start
jboss-eap.sh is neither service nor target!?

Import service in sytemd

Now we need to get this service into systemd. To do that, You need to add below block on top of /etc/init.d/jboss-eap.sh . Make sure you edit it exactly since its an LSB compliant format read by the system. This needs to go below the shell opening line of script !/bin/sh and before the rest of the script.

### BEGIN INIT INFO
# Provides:          jboss-eap
# Required-Start:
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: jboss eap service
# Description:       jboss eap server for suse linux
### END INIT INFO

You are almost there! Import the service into systemd using below command –

root@kerneltalks # systemctl enable jboss-eap
jboss-eap.service is not a native service, redirecting to systemd-sysv-install
Executing /usr/lib/systemd/systemd-sysv-install enable jboss-eap

Now your service is available in systemctl to control. You can control service using commands like systemctl start jboss-eap, systemctl stop jboss-eap, systemctl status jboss-eap

root@kerneltalks # systemctl start jboss-eap
● jboss-eap-rhel.service - LSB: jboss eap service
   Loaded: loaded (/etc/init.d/jboss-eap-rhel.sh; bad; vendor preset: disabled)
   Active: active (running) since Thu 2019-06-20 1:23:23 IST; 10s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 10625 ExecStart=/etc/init.d/jboss-eap-rhel.sh start (code=exited, status=0/SUCCESS)
 Main PID: 12346 (java)
......

You have configured Jboss eap to run as service in Suse Linux.

What are the huge pages in Linux?

Learn about huge pages in Linux. Understand what is huge pages, how to configure it, how to check the current state, and how to disable it.

HugePages in Linux

In this article, we will walk you through details about huge pages so that you will be able to answer: what are huge pages in Linux? How to enable/disable huge pages? How to determine huge page value? in Linux like RHEL6, RHEL7, Ubuntu, etc.

Lets start with Huge pages basics.

What is Huge page in Linux?

Huge pages are helpful in virtual memory management in the Linux system. As the name suggests, they help is managing huge size pages in memory in addition to standard 4KB page size. You can define as huge as 1GB page size using huge pages.

During system boot, you reserve your memory portion with huge pages for your application. This memory portion i.e. these memory occupied by huge pages is never swapped out of memory. It will stick there until you change your configuration. This increases application performance to a great extent like Oracle database with pretty large memory requirements.

Why use huge page?

In virtual memory management, the kernel maintains a table in which it has a mapping of the virtual memory address to a physical address. For every page transaction, the kernel needs to load related mapping. If you have small size pages then you need to load more numbers of pages resulting kernel to load more mapping tables. This decreases performance.

Using huge pages means you will need fewer pages. This decreases the number of mapping tables to load by the kernel to a great extent. This increases your kernel-level performance which ultimately benefits your application.

In short, by enabling huge pages, the system has fewer page tables to deal with and hence less overhead to access/maintain them!

How to configure huge pages?

Run below command to check current huge pages details.

root@kerneltalks # grep Huge /proc/meminfo
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

In the above output, you can see the one-page size is 2MB Hugepagesize and a total of 0 pages on the system HugePages_Total. This huge page size can be increased from 2MB to max 1GB.

Run below script to get how much huge pages your system needs currently. The script is from Oracle and can be found.

#!/bin/bash
#
# hugepages_settings.sh
#
# Linux bash script to compute values for the
# recommended HugePages/HugeTLB configuration
#
# Note: This script does calculation for all shared memory
# segments available when the script is run, no matter it
# is an Oracle RDBMS shared memory segment or not.
# Check for the kernel version
KERN=`uname -r | awk -F. '{ printf("%d.%d\n",$1,$2); }'`
# Find out the HugePage size
HPG_SZ=`grep Hugepagesize /proc/meminfo | awk {'print $2'}`
# Start from 1 pages to be on the safe side and guarantee 1 free HugePage
NUM_PG=1
# Cumulative number of pages required to handle the running shared memory segments
for SEG_BYTES in `ipcs -m | awk {'print $5'} | grep "[0-9][0-9]*"`
do
   MIN_PG=`echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -q`
   if [ $MIN_PG -gt 0 ]; then
      NUM_PG=`echo "$NUM_PG+$MIN_PG+1" | bc -q`
   fi
done
# Finish with results
case $KERN in
   '2.4') HUGETLB_POOL=`echo "$NUM_PG*$HPG_SZ/1024" | bc -q`;
          echo "Recommended setting: vm.hugetlb_pool = $HUGETLB_POOL" ;;
   '2.6' | '3.8' | '3.10' | '4.1' ) echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
    *) echo "Unrecognized kernel version $KERN. Exiting." ;;
esac
# End

You can save it in /tmp as hugepages_settings.sh and then run it like below :

root@kerneltalks # sh /tmp/hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 124

Output will be similar to some number as shown in above sample output.

This means your system needs 124 huge pages of 2MB each! If you have set 4MB as page size then the output would have been 62. You got the point, right?

Configure hugepages in kernel

Now last part is to configure the above-stated kernel parameter and reload it. Add below value in /etc/sysctl.conf and reload configuration by issuing sysctl -p command.

vm.nr_hugepages=126

Notice that we added 2 extra pages in the kernel since we want to keep a couple of pages spare than the actual required number.

Now, huge pages have been configured in the kernel but to allow your application to use them you need to increase memory limits as well. The new memory limit should be 126 pages x 2 MB each = 252 MB i.e. 258048 KB.

You need to edit below settings in /etc/security/limits.conf

soft memlock 258048 
hard memlock 258048

Sometimes these settings are configured in app-specific files like for Oracle DB its in  /etc/security/limits.d/99-grid-oracle-limits.conf

That’s it! You might want to restart your application to make use of these new huge pages.

How to disable hugepages?

HugePages are generally enabled by default. Use the below command to check the current state of huge pages.

root@kerneltalks # cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

[always] flag in output shows that hugepages are enabled on system.

For RedHat based systems file path is /sys/kernel/mm/redhat_transparent_hugepage/enabled

If you want to disable huge pages then add transparent_hugepage=never at the end of kernel line in /etc/grub.conf and reboot the system.

How to restart service in Linux

Article explaining service management in Linux. Learn how to restart service in Linux distro like Red Hat, Debian, Ubuntu, CentOS, etc.

Service management in Linux

Managing services in Linux is one of the frequent task sysadmins need to take care of. In this post, we will be discussing several operations like –

  • How to stop service in Linux
  • How to start service in Linux
  • How to restart service in Linux
  • How to check the status of service in Linux

Different distributions have different ways of service management. Even within the same distro, different versions may have different service management aspects. Like RHEL 6 and RHEL7 has different commands to manage services.

Let’s see service related tasks in various flavors of Linux –

How to stop service in Linux

Service can be stopped with below commands (respective distro specified)

# service <name> stop (RHEL6 & lower, Ubuntu, CentOS, Debian, Fedora)

# systemctl stop <name>.service  (RHEL7)

# stop <name> (Ubuntu with upstart)

here <name> is service name like telnet, NTP, NFS, etc. Note that upstart is pre-installed with Ubuntu 6.10 later, if not you can install using the APT package.

Newer versions are implementing systemctl now in place of service command. Even if you use service command in RHEL7 then it will call systemctl in turns.

# service sshd-keygen status
Redirecting to /bin/systemctl status  sshd-keygen.service
● sshd-keygen.service - OpenSSH Server Key Generation
   Loaded: loaded (/usr/lib/systemd/system/sshd-keygen.service; static; vendor preset: disabled)
   Active: inactive (dead)
-----output clipped-----

In the above output, you can see it shows you which systemctl command its executing in place of service command.  Also, note that it appends .service to service_name supplied to service command.

Old service commands like RHEL6 & lower, prints status of operation as OK (success) or FAILED (failure) for start, stop, restart operations. systemctl the command doesn’t print any output on the console.

How to start service in Linux

Starting service follows same above syntax.

# service <name> start (RHEL6 & lower, Ubuntu, CentOS, Debian, Fedora)

# systemctl start <name>.service  (RHEL7)

# start <name> (Ubuntu with upstart)

How to restart service in Linux

# service <name> restart (RHEL6 & lower, Ubuntu, CentOS, Debian, Fedora)

# systemctl restart <name>.service  (RHEL7)

# restart <name> (Ubuntu with upstart)

It stops service and then immediately starts it. So basically its a combined command of above two.

Mostly to reload edited new configuration we seek restart of service. But this can be done without restarting it provided service supports reload config. This can be done by using reload option instead of restart.

How to check the status of service in Linux

Checking the status of service makes you aware of if service is currently running or not. Different distros give different details about service in the output of status. Below are a few examples for your reference.

Service status information in Ubuntu :

# service cron status                                                                                                                                         
● cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2017-03-10 17:53:23 UTC; 2s ago
     Docs: man:cron(8)
 Main PID: 3506 (cron)
    Tasks: 1
   Memory: 280.0K
      CPU: 1ms
   CGroup: /system.slice/cron.service
           └─3506 /usr/sbin/cron -f

Mar 10 17:53:23 ip-172-31-19-90 systemd[1]: Started Regular background program processing daemon.
Mar 10 17:53:23 ip-172-31-19-90 cron[3506]: (CRON) INFO (pidfile fd = 3)
Mar 10 17:53:23 ip-172-31-19-90 cron[3506]: (CRON) INFO (Skipping @reboot jobs -- not system startup)

It has details about the service state, its man page, PID, CPU & MEM utilization, and recent happenings from the log.

Service status information in RHEL6:

# service crond status
crond (pid  1474) is running...

It only shows you PID and state of service.

Service status information in RHEL7:

# systemctl status crond.service
● crond.service - Command Scheduler
   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2017-03-10 13:04:58 EST; 1min 2s ago
 Main PID: 499 (crond)
   CGroup: /system.slice/crond.service
           └─499 /usr/sbin/crond -n

Mar 10 13:04:58 ip-172-31-24-59.ap-south-1.compute.internal systemd[1]: Started Command Scheduler.
Mar 10 13:04:58 ip-172-31-24-59.ap-south-1.compute.internal systemd[1]: Starting Command Scheduler...
Mar 10 13:04:58 ip-172-31-24-59.ap-south-1.compute.internal crond[499]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 85% if used.)
Mar 10 13:04:59 ip-172-31-24-59.ap-south-1.compute.internal crond[499]: (CRON) INFO (running with inotify support)

It prints all details as Ubuntu but doesn’t show CPU and memory utilization, manpage.

List all services on the system

If you want to see all services running on the system and their statuses then you can use below command :

# service --status-all (RHEL6 & lower, Ubuntu, CentOS, Debian, Fedora)

# systemctl list-units --type service --all (RHEL7)

It will present you list of all services and their status with few other details.

What is umask value? How to set it up?

Learn everything about umask value. What is umask value? What is the best default umask? How to set it up in Linux and Unix? & How to calculate umask?

One of the basic topics in learning Linux or Unix is umask value. UMASK is a user file/directory permission mask value and is 4 digits octal value! Whenever a user creates a file or directory kernel grants it some by default permissions. Those are base permissions. For file, it’s 666 (i.e. rw-rw-rw) means read, write to all (owner, group, others), and for directory its 777 (i.e. rwxrwxrwx) means read, write, execute to all.

Here user mask plays its role. The user permission mask is the octal value that is used to determine file/directory permission when they are created by the user. Umask value subtracted bitwise from base permissions and final permission is determined for newly created files and directories.

How to calculate umask?

For example, if umask value is 0022 then newly created files will have permission 0666-0022=0644 (i.e. rw-r–r–) means read to all and write to the owner only. There are plenty of combinations can be used depending on your requirement. You can refer below calculation table for determining your expected umask value:

umask value (Bit from left to right)For whomFile base permissionDirectory base permission
1st00
2ndOwner67
3rdGroup67
4thOthers67

So, you need to decide which final permission you want on newly created file and directories. Once that is finalized you can have reverse calculation with 666 & 777 and decide your umask value.

Read also : What is ulimit value?

What is best default umask?

Below are few standard best default umask values which can be used :

umask valueFinal File permissionFinal directory permissionUseful for
022644755 Normal user. Others have read access only
002664775 Group usage. Only group members has access
077600700 Complete privacy. No other user can access your data

How to setup umask in Linux/Unix?

umask value can be set up using simple command umask followed by its value. But, this value will be set only for that current active shell session.

# umask 022
# touch testfile
# ll
total 0
-rw-r--r--. 1 root root 0 Feb  1 01:03 testfile

# umask 077
# touch testfile1
# ll
total 0
-rw-------. 1 root root 0 Feb  1 01:04 testfile1


Observe in the above output that file permissions defer when we set different umask values.

To set this up permanently, define this command in the login profiles of users. /etc/profile value can be overridden by the user’s own profile which executes after that. For all systemwide users define it /etc/profile or /etc/bashrc file. For user-specific values, define them in  ~/.profile (Korn / Bourne shell) ~/.cshrc file (C shells), ~/.bash_profile (Bash shell) these shell specific profiles in their home directories.

You need to open a specific profile with vi editors and append umask <value> line at the end.

Setup umask with permission 

If you are not good at remembering numbers and want to avoid octal notation, then you can define umask with permission letters too. Syntex will be as below :

# umask u=rwx,g=,o=

# ll
total 0
-rw-------. 1 root root 0 Feb  1 01:12 testfile3

Here, we set umask with defining permissions at the user, group, and owner level (500). Notice that there is no space in between but permissions are separated by commas.

6 ways to manage service startups using chkconfig in Linux

Learn chkconfig command to list, turn on, or turn off system services during different run levels. Also, see how to control xinetd managed system service.

The chkconfig utility in Linux is a command-line tool to manage system services startups in run levels starting from 0 to 6. Run levels are different system stages in which the system can run with different numbers and combinations of services available for its users. There are mainly 7 run levels defined in the kernel world whereas 0,1 and 6 are not relative in this post. 0,6 run levels are boot/shut related whereas 1 is the single-user mode and we are seeing service management here which is normally comes in a picture for multi-user mode. So only 2,3,4,5 are the run levels that are covered by chkconfig utility when you are altering any services.

chkconfig controls which system service starts in which run level. It can even completely shuts off service so that it won’t run at any run level too. There are xinetd controlled system services that can be turned on or off irrespective of run level. These can be managed through chkconfig too.

Chkconfig is capable of below tasks:

  1. Overview of list of services and their run-level wise availability
  2. Details of individual system service
  3. Enable service at certain/all run levels
  4. Disable service
  5. Enable xinetd managed service
  6. Disable xinetd managed service

If you are on the Ubuntu server then probably chkconfig won’t work on Ubuntu. You can alternatively use update-rc.d command there.

We will see each of the above options in detail with related options and examples.

1. Overview of services and their run-level availability :

For this task, chkconfig displays a list of system services. Against every service, it displays all run levels 0 to 6 and on/off parameter. On means, service is enabled at that run level, and off means service is disabled at that run level. To view this you can run chkconfig command without any argument or with --list option.

# chkconfig --list
NetworkManager  0:off   1:off   2:off   3:off   4:off   5:off   6:off
abrt-ccpp       0:off   1:off   2:off   3:on    4:off   5:on    6:off
abrt-oops       0:off   1:off   2:off   3:on    4:off   5:on    6:off
abrtd           0:off   1:off   2:off   3:on    4:off   5:on    6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
auditd          0:off   1:off   2:on    3:on    4:on    5:off   6:off
autofs          0:off   1:off   2:off   3:on    4:on    5:on    6:off

-----output clipped-----
xinetd based services:
        chargen-dgram:  off
        chargen-stream: off
        time-stream:    off
----- output clipped -----

In the above output for example system service autofs is enabled for run level 3,4,5 and disabled for 0,1,2,6. It also shows xinetd based service status at the bottom. These services only have on or off status (no run level based status)

2. Details of individual service

In this task the same output as above can be obtained only for a particular service. It is as good as grepping out that service line from the above output. This task can be accomplished by using the service name as an argument to --list option.

# chkconfig --list nfs
nfs             0:off   1:off   2:off   3:off   4:off   5:off   6:off

# chkconfig --list rsync
rsync           off

3. Enable service at certain/all run levels :

Let’s see how to enable service for a particular/all run level. For this task, you need to specify levels (--level) on which services need to enable, followed by service name and lastly on a state.

# chkconfig --level 34 autofs on

In above example we are enabling autofs service in run level 3 and 4.

To enable it in all run levels i.e. 2,3,4,5 you can skip --level option.

# chkconfig autofs on

The above example enables autofs system service at all run levels. You can verify if the service state is set properly as specified in the command, by viewing chkconfig --list output.

4. Disable service

To disable service at certain/all run levels, sane above command can be used only ‘off’ state needs to be specified at the end instead of ‘on’ state.

# chkconfig --level 34 autofs off <<turns off at run level 3 & 4

# chkconfig autofs off <<turns off on all run levels

Make a note that this change is not immediate. Enabling or disabling services will change settings but takes effect only when the system will enter a specific run level after the execution of the command.

5. Enable xinetd managed service:

Since xinetd managed services cant be tagged to run-levels, you can not specify --level option with commands associated with them. To enable xinetd managed service, you need to mention the service name followed by ‘on’ state.

# chkconfig rsync on

Make a note that, change in xinetd managed services will be instant after the execution of the command.

6. Disable xinetd managed service:

To disable xinetd managed services opt ‘off’ state in above command.

# chkconfig rsync off




Observe state change in chkconfig --list output.

How to change your shell prompt to fancy one instantly

Learn to change shell prompt with your chosen character or value. Different values or shell variables can be defined to be shown as shell prompt.

After the user logged in to the system through Putty or command line he is greeted with blinking cursor in front of something called “Shell prompt”! Generally, the shell prompt with # denotes superuser and with $ denotes normal user. But going beyond these mainstream prompts, most of the admins choose the custom prompt for them and their users.

The most famous prompt used is showing the present working directory in prompt. So that users know in which directory he is while executing any command. Another widely used prompt is showing hostname. This ensures the user that he is working on the right terminal when many terminal windows are open. In this post, we will see how to set these prompts and some fancy prompts too.

Where to define Shell prompt :

Shell prompt is defined by PS1 variable in the profile file. This profile file can be any profile that is executed on user login. If multiple profiles have multiple values defined for PS1 then the last profile executed will decide the final value for PS1. For example when user logs in below profile execution can be followed :

/etc/profile -> ~/.bash_profile -> ~/.bashrc -> /etc/bashrc

In above flow system-wide profile i.e. /etc/profile calls bash profile which resides in the user’s home directory. This local profile calls bashrc script residing in the home directory. This bashrc calls up system-wide /etc/bashrc script to set the environment. In this case, PS1 value defined in /etc/bashrc would be the final one.

Sometimes there were no scripts called from profile then user’s home directory profile would be last resort to define PS1. If the profile file is missing in the user’s home directory the PS1 defined in /etc/profile will decide how your prompt looks.

How to define shell prompt :

Now, you know the file where prompt can be defined. Let’s see how to define it. It can be defined in a very basic way as below :

PS1=":->"
export $PS1

Here we are defining prompt as the symbol :-> The export command is not necessary but it’s good to have it in some flavors of Linux or Unix. Even you can test it by running command PS1=":->" on your terminal and you can see immediately your prompt will be changed to :->

You can even use an if-else loop in the profile file to decide which prompt should be served for particular users or terminal types.

Different useful prompts :

Below is the useful list of variables can be used in prompts :

Code
Description
PS1=”[$USER@$HOSTNAME]$” Shows prompt as [username@hostname]$
PS1=”[$USER@$HOSTNAME $PWD]$” Shows prompt as [username@hostname Present_directory]$
PS1=”[$HOSTNAME $PWD]$” Shows prompt as [hostname present_directory]$
PS1=”$HOSTNAME >” Shows prompt as hostname >

You can choose your own variations. See above-listed prompts in action below :

$PS1="[$USER@$HOSTNAME]$"
[user4@testsrv2]$

$PS1="[$USER@$HOSTNAME $PWD]$"
[user4@testsrv2 /home/user4]$

$PS1="[$HOSTNAME $PWD]$"
[testsrv2 /home/user4]$

$PS1="$HOSTNAME >"
testsrv2 >

Observe the first prompt is just $ sign. After each PS1 value change, prompt changes accordingly.

Some fancy prompts :

Here are some fancy prompts for fun!

$PS1=">-->"
>-->

$PS1="-=(^_^)=-:"
-=(^_^)=-:

$PS1="\m/ (-_-) \m/ :"
\m/ (-_-) \m/ :

$PS1="$USER rules $HOSTNAME >"
user4 rules testsrv2>

Hope you liked the post. Drop us your feedback, suggestions in comments below! Do follow us on Facebook, Twitter & Google+

How to do safe and graceful Measureware service restart in HPUX

A how-to guide for safe and graceful measureware service restart on HPUX machines. Learn how to preserve old log files during service restart and avoid overwriting them.

Measureware service is a native utility to HPUX for performance measurement. It is responsible to collect system utilization data in the background. Measureware agent mwa runs in background and stores data in logfiles called datafiles.  If you attempt measureware service restart without moving logfiles then it will overwrite current files and all historic data is on the toss. Hence you need to stop it then move data files to another location and then start it. In this sequence, you prompt agents to create new blank data files to save data.

You can view the current status of all measureware services using below command :

# mwa status all
 Perf Agent status:
    Running scopeux               (Perf Agent data collector) pid 2814
    Running midaemon              (Measurement Interface daemon) pid 2842
    Running ttd                   (ARM registration daemon) pid 2703

 Perf Agent Server status:

    Running ovcd                  (OV control component) pid 3483
    Running ovbbccb               (BBC5 communication broker) pid 3484
    Running coda                  (perf component) pid(s) 3485
       Configured DataSources(1)
                  SCOPE

    Running perfalarm             (alarm generator) pid(s) 2845

If any of the components are not running or having issues then it may call for measureware service restart. Let’s see the process of the graceful shutdown and the start of measureware services in HPUX.

Read also another performance measurement tool System Activity Report (SAR) in the below series :

1. Stop mwa

Stop all measureware services with single command as below :

# mwa stop all

Shutting down Perf Agent collection software
         Shutting down scopeux, pid(s) 2814
         The Perf Agent collector, scopeux has been shut down successfully.
NOTE:   The ARM registration daemon ttd will be left running.

Shutting down the alarm generator perfalarm, pid(s) 2845
         The perfalarm process has terminated

OVOA is running. Not shutting down coda

As you can see in the above output ttd is left running by command. You need to kill it using below command :

# ttd -k

Also, mideamon still runs after the above command. You can terminate it using :

#  midaemon -T

These three commands collectively shut off everything related to measureware services. You can confirm if midaemon, ttd and scopeux are down with status command again :

#  mwa status all
 Perf Agent status:
WARNING: scopeux    is not active (Perf Agent data collector)
WARNING: midaemon   is not active (Measurement Interface daemon)
WARNING: ttd        is not active (ARM registration daemon)

 Perf Agent Server status:

    Running ovcd                  (OV control component) pid 3483
    Running ovbbccb               (BBC5 communication broker) pid 3484
    Running coda                  (perf component) pid(s) 3485
       Configured DataSources(1)
                  SCOPE

WARNING: perfalarm is not active (alarm generator)

This ensures you can proceed with log movement before starting mwa again.

2. Log movement

Datafiles (all starts with log) resides in /var/opt/perf/datafiles directory. List of datafiles is as below :

# ll /var/opt/perf/datafiles/log*
-rw-r--r--   1 root       users      11064908 Jan  1 03:05 /var/opt/perf/datafiles/logappl
-rw-r--r--   1 root       root       43951620 Jan  1 03:05 /var/opt/perf/datafiles/logdev
-rw-r--r--   1 root       users      9556384 Jan  1 03:05 /var/opt/perf/datafiles/logglob
-rw-r--r--   1 root       root         15716 Jan  1 03:01 /var/opt/perf/datafiles/logindx
-rw-r--r--   1 root       users           15 Nov  4  2009 /var/opt/perf/datafiles/logpcmd0
-rw-r--r--   1 root       root       76492020 Jan  1 03:05 /var/opt/perf/datafiles/logproc
-rw-r--r--   1 root       root       96153856 Jan  1 03:05 /var/opt/perf/datafiles/logtran

Now move current data files to a different directory. You can use below small inline scripts to do this or you can manually move them one by one.

# cd /var/opt/perf/datafiles
# nowis=`date +%d%b%y-%H:%M`
# mkdir /var/opt/perf/datafiles.old.`echo $nowis`
# cp log* /var/opt/perf/datafiles.old.`echo $nowis`

Make sure you copied datafiles to the destination correctly and proceed to start services again.

3. Start mwa

Start it using below command :

#  mwa start all

The Perf Agent scope collector is being started.
         The ARM registration daemon
         /opt/perf/bin/ttd has been started.

         The Performance collection daemon
         /opt/perf/bin/scopeux has been started.

         The coda daemon /opt/OV/lbin/perf/coda is already running.
The Perf Agent alarm generator is being started.
         The alarm generator /opt/perf/bin/perfalarm
         has been started.

Observe while shutting down we used three commands for shutting different components but while starting up it came up with the single command. You can check the status with mwa status all command to make sure all components are started. This pretty much sums up how to do a safe and graceful measureware service restart.

All examples on this post are from the machine running HPUX 11.31. Let us know if you have any queries, suggestions, corrections in comments.

4 steps guide for SMTP configuration in HPUX

Learn how to configure SMTP in HPUX machines. Know configuration file locations, parameters in config files, and testing commands.

SMTP is the short name for the Simple Mail Transfer Protocol. SMTP is an Internet standard for electronic mail (e-mail) transmission. We have already seen the SMTP configuration in Linux. In this post, we will be seeing SMTP in HPUX.

Pre-requisite

  • Hostname and IP address of SMTP server should be known (e.g. we will use mailserver.xyz.com 10.10.2.5)
  • The client should be able to reach the SMTP server over the network

Configurations

Step 1.

Add SMTP server entry in /etc/hosts file using vi editor or concatenate using echo command below.

# echo "10.10.2.5   mailserver.xyz.com" >> /etc/hosts

# cat /etc/hosts |grep -i mail
10.10.2.5   mailserver.xyz.com

Step 2.

Update daemon configuration file /etc/rc.config.d/mailservs to start the SMTP services with server startup. Edit the file with vi editors and update below entry:

SENDMAIL_SERVER=1

Add the SMTP server detail into SMTP configuration file /etc/mail/sendmail.cf. Edit below two entities

DMxyz.com
Dj<hostname>.com <<Add clients hostname
 DSmailserver.xyz.com
#C{E}root <<hash this entry

Step 3.

Now restart the SMTP daemon to take up this new configuration:

# /sbin/init.d/sendmail stop
Shutting down sendmail          [Done]
Shutting down sm-client         [Done]

# /sbin/init.d/sendmail start
Starting sendmail               [Done]
Starting sm-client              [Done]

Now check if sendmail is running using below command:

# ps -ef |grep -i sendmail
    root  1185     1  0  Nov 11  ?        61:33 sendmail: accepting connections on port 25
    root 21945 21815  0 03:18:28 pts/0     0:00 grep -i sendmail

Step 4.

Send a test mail and verify it.

# echo test | /usr/sbin/sendmail -v info@xyz.com
info@xyz.com... Connecting to mailserver.xyz.com via relay...
220 mailserver.xyz.com  ESMTP Postfix
>>> EHLO xyz.com
250-mailserver.xyz.com 
250-PIPELINING
250-SIZE 25600000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
>>> MAIL From:<root@xyz.com> SIZE=5
250 2.1.0 Ok
>>> RCPT To:<info@xyz.com>
250 2.1.5 Ok
>>> DATA
354 End data with <CR><LF>.<CR><LF>
>>> .
250 2.0.0 Ok: queued as 715C48203C
info@xyz.com... Sent (2.0.0 Ok: queued as 715C48203C)
Closing connection to mailserver.xyz.com
>>> QUIT
221 2.0.0 Bye

If you don’t receive an email, check logs under /var/adm/syslog/mail.log for troubleshooting.

5 steps guide for SMTP configuration in Linux

Learn how to configure SMTP in Linux machines. Know configuration file locations, parameters in config files, and testing commands.

Simple Mail Transfer Protocol. SMTP is one of the important services in any production system. Nowadays, mail notifications became important to monitor systems in real-time. Hence, it becomes essential to know how to configure mail utilities on servers. To enable any mail program on the system, SMTP is a basic component. It’s a very easy and quick procedure to setup SMTP on servers.

Pre-requisite :

  • Hostname and IP address of SMTP server should be known (e.g. we will use mailserver.xyz.com 10.10.2.5)
  • The client should be able to reach SMTP server over a network

Configurations :

Its 5 steps procedure to setup SMTP client on Linux.

Step 1.

Add SMTP server entry in /etc/hosts file using vi editor or concatenate using echo command below.

# echo "10.10.2.5   mailserver.xyz.com" >> /etc/hosts
# cat /etc/hosts |grep -i mail
10.10.2.5   mailserver.xyz.com
Step 2.

We need to edit the macro configuration file /etc/mail/sendmail.mc. Search and edit below parameters in this file :

  • define(`SMART_HOST',`mailserver.xyz.com'): Smart relay server name
  • define(`confDOMAIN_NAME',`xyz.com')dnl: Valid domain name
  • FEATURE(always_add_domain)dnlalways masquerades email address
  • FEATURE(`allmasquerade')dnl: rewrite both from/to relative to the local machine.
  • MASQUERADE_DOMAIN(`xyz.com.')dnl: Domain for masquerading emails
  • MASQUERADE_AS(`xyz.com')dnl: All mails masquerades as came from the defined domain
Step 3.

Once the above changes are done, you need to compile the mc file so that all these changes of the macro (mc) file will be transferred to the config ( cf) file using m4 utility.

# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Step 4.

Edit below parameters in /etc/mail/submit.cf so that mails will be submitted to defined domain.

D{MTAHost} mailserver.xyz.com 
Djxyz.com: Define this in case of sendmail won’t able to determine your domain.
DSmailserver.xyz.com: Smart relay host

Step 5.

Finally, restart mail services to take up this new configurations :

# service sendmail restart
# service postfix restart

You are done! Send a test email with the below command and check if you receive it.

# echo test |sendmail -v info@xyz.com
[<-] 220 mailserver.xyz.com ESMTP Postfix
[->] HELO testsrv2
[<-] 250 mailserver.xyz.com
[->] MAIL FROM:<root@xyz.com>
[<-] 250 2.1.0 Ok
[->] RCPT TO:<info@xyz.com>
[<-] 250 2.1.5 Ok
[->] DATA
[<-] 354 End data with <CR><LF>.<CR><LF>
[->] Received: by testsrv2 (sSMTP sendmail emulation); Fri, 23 Dec 2016 02:29:07 +0800
[->] From: "root" <root@xyz.com>
[->] Date: Fri, 23 Dec 2016 02:29:07 +0800
[->] test
[->]
[->] .
[<-] 250 2.0.0 Ok: queued as 19F75822B8
[->] QUIT
[<-] 221 2.0.0 Bye

If you don’t receive an email, check logs under /var/log/maillog for troubleshooting.

Build Syslog server in Linux for centralized log management

Step by step guide to configure Syslog Server in a Linux environment. Learn how to enable remote Syslog logging in Linux for centralized log management.

In many It infrastructure environments, clients choose to have one centralized Syslog server in which all logs from remote systems can be collected. It then easier to filter, monitor, verify a report in a single location rather than querying all systems in infra. In this post, we will be seeing how to configure Linux machine to act as a Syslog server.

In the configuration, there are two parts. First server-side configuration to be done on the Linux machine which will act as Syslog server. Secondly, client-side configuration to be done on a remote system that will be sending logs to the Syslog server.

Server side configurations:

A machine which will be acting as Syslog server should have below pre-requisites done :

  1. syslog daemon i.e. syslogd should be up and running
  2. portmap and xinetd services should be running
  3. Targeted client machine’s IP range should be able to reach the Syslog server over network.
# service syslog status
syslogd (pid  3774) is running...
klogd (pid  3777) is running...
# service portmap  status
portmap (pid 3891) is running...
# service xinetd  status
xinetd (pid  4410) is running...

Once you make sure all related services are running, proceed to edit syslogd configuration file i.e. /etc/syslog.conf. You need to add -r option in the configuration file which will enable daemon to receive logs from remote machines.

# cat /etc/sysconfig/syslog

# Options to syslogd
# -m 0 disables 'MARK' messages.
# -r enables logging from remote machines
# -x disables DNS lookups on messages recieved with -r
# See syslogd(8) for more details
SYSLOGD_OPTIONS="-m 0"
# Options to klogd
# -2 prints all kernel oops messages twice; once for klogd to decode, and
#    once for processing with 'ksymoops'
# -x disables all klogd processing of oops messages entirely
# See klogd(8) for more details
KLOGD_OPTIONS="-x"
#
SYSLOG_UMASK=077
# set this to a umask value to use for all log files as in umask(1).
# By default, all permissions are removed for "group" and "other".

Here you can see a row with parameter SYSLOGD_OPTIONS="-m 0". This needs to be added with -r option like  SYSLOGD_OPTIONS="-r -m 0"

Edit the conf file with a text editor like vi and add -r option as stated above. To take up these new changes restart Syslog service.

# service syslog restart
Shutting down kernel logger:          [  OK  ]
Shutting down system logger:          [  OK  ]
Starting system logger:               [  OK  ]
Starting kernel logger:               [  OK  ]

Now your server Syslog daemon is ready to accept logs from remote machines. All messages from remote machines and Syslog server’s own Syslog will be logged in /var/log/messages on Syslog server. Its own messages will be having “localhost” in 2nd field after the date and remote machine logs will be having IP/hostname instead of localhost in the 2nd field.

It should look like below once it starts populating remote machine’s logs too. First entry beings its own and second one being remote server’s log.

Nov 10 12:34:44 localhost syslogd 1.4.1: restart (remote reception).
Nov 10 12:34:44 server3  snmpd[4380]: Connection from UDP: [10.100.49.125]:55234

Client side configurations:

In client machine, you need to edit Syslog configuration file /etc/syslog.conf. Here you need to instruct Syslog daemon to send logs to remote Syslog server.

Open /etc/syslog.conf configuration file and append user.* @[ server IP] to end of it. In which server IP is your Syslog server IP. If you have mentioned Syslog server IP in /etc/hosts of client machine then you can give hostname in above entry instead of IP.

user.* defines the type of log messages to be sent to the Syslog server. If you want to log all messages to the Syslog server you can use *.* or you can choose the type of logs defined in this config file itself. Read the below file and you will get to know different types. Defining *.* is not advisable since it will be flooding logs on the Syslog server and its storage might get full if you have many machines sending logs to the server at a time.

This should look like below. Check last line of file :

# cat /etc/syslog.conf

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

user.*          @10.12.2.5

After editing conf file, restart syslog daemon to get this new config in action.

You can send test log to check if your setup is working using below command :

# logger -p user.info “Test log message”

This will send a user.info type messages to Syslog locally. It will be logged to local /var/log/messages and also gets forwarded to the Syslog server on the mentioned IP. You should see below entries :

On local i.e. client 
# tail -1 /var/log/messages
Dec  7 01:27:09 localhost root: “Test log message”

On syslog server 
# tail -1 /var/log/messages
Dec  7 01:27:09 server3 root: “Test log message”

This will confirm your Syslog server is accepting remote logs perfectly and the machine you configured as the client is sending logs to the server too!