UnixPedia : HPUX / LINUX / SOLARIS: December 2016

Wednesday, December 28, 2016

Resolving Port conflict on Unix

Application port number 50304 been used by Unix dm_TL_adapter, this happen if port are not reserved on the system. Port is taken by dm_TL_adapter and application not be able to start it. To resolve it.

1 - Find what is using the port with lsof command

[root@horses:/sbin/init.d]#
#-> lsof -i :50304
COMMAND    PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
dm_TL_ada 6774 root    3u  IPv4 0xe000000223094ac0      0t0  TCP *:50304 (LISTEN)

2 - try to stop or kill the process or consult expert if not sure about your action.
[root@horses:/sbin/init.d]#
#-> /sbin/init.d/diagnostic stop

[root@horses:/sbin/init.d]#
#-> ps -ef |grep -i 6774
    root  6774     1  0  Dec 17  ?         0:06 /usr/sbin/stm/uut/bin/tools/monitor/dm_TL_adapter
    root 29184 18309  1 04:51:29 pts/4     0:00 grep -i 6774

[root@horses:/sbin/init.d]#
#-> grep -i dm_TL_adapter *

[root@horses:/sbin/init.d]#
#-> kill -9 6774

3 - Re-validate the process and port usage.
[root@horses:/sbin/init.d]#
#-> ps -ef |grep -i 6774
    root  4473 18309  0 04:51:55 pts/4     0:00 grep -i 6774

[root@horses:/sbin/init.d]#
#-> lsof -i :50304

4 - Ask application team to start the application as port is freed.

[root@horses:/sbin/init.d]#
#-> lsof -i :50304

5 - after application start port is taken by application service.
[root@horses:/sbin/init.d]#
#-> lsof -i :50304
COMMAND   PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
jlaunch 12666 tqaadm99u  IPv4 0xe00000023c54a040      0t0  TCP *:50304 (LISTEN)

[root@horses:/sbin/init.d]#

Wednesday, December 21, 2016

Stop Cron Daemon from Sending Email for Each Job

Stop Cron Daemon from Sending Email for Each Job

Question sent in by Howard from Pasadena:

Q: I have some cron jobs that run overnight on my Linux systems.  Each of these jobs output information to a text file if I ever need to review.  Some are written to send emails via the mail command.  But since I put these scripts on a new system and added them to crontab, I am getting an email for each job that runs.  There are too maybe emails being sent to root. Is there a way to stop this behavior?

A: Crond typically sends an email when a cron job is run. It uses the MAILTO variable in /etc/crontab to determine who receives the email, by default this is root. There are several ways to stop this behavior.

1. Change the MAILTO variable to blank.

You can edit the /etc/crontab file and change the MAILTO variable to the following: 
MAILTO=""
This will effectively disable all emails from the cron daemon.  You can then decide from within the script to send mail using the mailx command or the command of your choice.

This is not my preferred method as I like to receive an email when there is an error with the cronjob.

2. Redirect STDOUT and STDERR to null to suppress output.  

By suppressing output of the script, there will be nothing for crond to send.

Add the following to the crontab entry to send all output (STDERR and STDOUT) to the /dev/null. 
>/dev/null 2>&1
For example:
0 5 * * * /example/script >/dev/null 2>&1This also has it's drawbacks as you will be suppressing any errors that may be helpful to debug problems with the script.

3. Configure crond to send the script output to the system log, and disable sending mail of output. 

You can configure crond by editing the /etc/sysconfig/crond file and changing the CRONDARGS line.  Adding the "-s" argument will send the output to the system log, and adding the "-m off" argument will disable crond from sending emails of the job output.

For example:
[root@centos7 ~]# cat /etc/sysconfig/crond
# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS=-s -m off

You will have to restart the crond service to read the new arguments:
#-> /etc/init.d/crond restartStopping crond:                                            [  OK  ]Starting crond:                                            [  OK  ]


Any of the above methods will work for completely suppressing emails from cron daemon when jobs run.  This is not ideal in my mind as I would like to be notified if errors occur in my cron jobs.  I prefer to either write my scripts to produce no output (no standard output-but still output errors), or redirect STDOUT only to /dev/null.  This will cause crond to ONLY send an email if an error has occurred.

Example of only redirecting STDOUT only:
0 5 * * * /example/script > /dev/null