Troubleshoot: -bash: fuser: command not found

If you are trying to use a command, fuser, that is used to identify process using lock file or socket file, and having the following error:

-bash: fuser: command not found

that means, your system doesn’t have the psmisc package installed. Usually, killall, fuser type of commands are under this package. CentOS 7 sometimes, do not install the package by default. To install it, run the following:

yum install psmisc -y

Once done, you should be able to use fuser command.

Troubleshoot: fatal: open lock file /var/lib/postfix/master.lock: unable to set exclusive lock

Error Message & Trace details:

One of my customer came with an error saying the postfix in his server isn’t working. The server was running CentOS 7, and the system postfix status was inactive, means not running. Although, the system queue was running I could see. The error that was returning while restarting/checking status was the following:

# service postfix status
Redirecting to /bin/systemctl status postfix.service
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2018-01-09 04:04:05 UTC; 1s ago
Process: 9201 ExecStart=/usr/sbin/postfix start (code=exited, status=1/FAILURE)
Process: 9197 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
Process: 9194 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
Main PID: 1358 (code=killed, signal=TERM)

Jan 09 04:04:03 twin7.hifrank.biz systemd[1]: Starting Postfix Mail Transport Agent...
Jan 09 04:04:03 twin7.hifrank.biz postfix/master[9273]: fatal: open lock file /var/lib/postfix/master.lock: unable to set exclusive lock: Resource tempo...vailable
Jan 09 04:04:04 twin7.hifrank.biz postfix/master[9272]: fatal: daemon initialization failure
Jan 09 04:04:05 twin7.hifrank.biz postfix/postfix-script[9274]: fatal: mail system startup failed
Jan 09 04:04:05 twin7.hifrank.biz systemd[1]: postfix.service: control process exited, code=exited status=1
Jan 09 04:04:05 twin7.hifrank.biz systemd[1]: Failed to start Postfix Mail Transport Agent.
Jan 09 04:04:05 twin7.hifrank.biz systemd[1]: Unit postfix.service entered failed state.
Jan 09 04:04:05 twin7.hifrank.biz systemd[1]: postfix.service failed.

How to fix:

The error to note here is the following:

fatal: open lock file /var/lib/postfix/master.lock

I first killed the smtp and smtpd processes that runs by postfix:

# killall -9 smtp
# killall -9 smtpd

But that didn’t solve the problem. I then used the fuser command to check which process holds the lock file:

# fuser /var/lib/postfix/master.lock
/var/lib/postfix/master.lock: 18698

Then we check the process 18698 and kill the responsible process:

# ps -axwww|grep 18698
9333 pts/0 S+ 0:00 grep --color=auto 18698

18698 ? Ss 4:28 /usr/libexec/postfix/master -w
# killall -9 /usr/libexec/postfix/master
or
# kill -9 18698

Once the process is killed, you can now start the postfix:

# service postfix start
# service postfix status|grep Active
Redirecting to /bin/systemctl status postfix.service
Active: active (running) since Tue 2018-01-09 04:15:50 UTC; 4min 45s ago

Troubleshoot: killall command not found in centos 7

Problem:

If you are using a centos 7 minimal installation, and trying to kill process by name using the command ‘killall’, you are most likely going to see the error:

# killall -9 php
killall: command not found

The error appears because CentOS 7 encourages you to use pkill instead of killall to kill process by name. pkill has versatile application, although, it can be used to kill process by name same as killall.

How to kill process by name in Centos 7

You can use pkill. pkill is a simple command. It’s syntax is as following:

# pkill processname

For example, if you want to kill all the php process, run:

# pkill php

Note: It will kill all the processes that match php. To list the process that pkill going to kill, you can use pgrep as following:

# pgrep -l php

How to use killall in Centos 7

If you do not want to use pkill, and keep using killall commands in centos 7, this is also possible. killall is a part of psmisc yum package. All you have to do, is to install psmisc in your system using yum

# yum install psmisc
# killall -9 php

 

How to install ifconfig in CentOS 7

CentOS 7 doesn’t come with ifconfig tools. It encourages users to use ‘ip’ tool for network administration. Although, it is still possible to use ifconfig with CentOS 7. ifconfig is a part of net-tools package. All you have to do is to install the net-tools package using yum.

How to install ifconfig in CentOS 7

Run the following command to install net-tools package in CentOS 7, this will install ifconfig as well:

# yum install net-tools -y
# ifconfig

Linux How To: Install IPTABLES in CentOS 7 / RHEL 7 Replacing FirewallD

CentOS 7 / RHEL 7 doesn’t come with iptables by default. It uses a full functional firewall system called ‘firewalld’. I have been a big fan of iptables and it’s capability from the very first, and since I have switched to CentOS 7, I couldn’t stop using it. I had to stop firewalld and install iptables in all of my CentOS 7 installation and start using iptables rules as I was using before. Here is a small How To guide on installing Iptables and disabling firewalld from a CentOS 7 or RHEL 7 or a similar variant distro.

How to Install IPTABLES in CentOS 7

To begin using iptables, you need to download and install iptables-service package from the repo. It isn’t installed automatically on CentOS 7. To do that, run the following command:

# yum install iptables-services -y

How to stop the firewalld service and start the Iptables service

Once the iptables-serivces package is installed, you can now stop the firewalld and start the iptables. Keeping both kind of network filtering too can create conflicts and it is recommended to use any out of two. To do that run the following:

# systemctl stop firewalld
# systemctl start iptables

Now to disable firewalld from the starting after the boot, you need to disable the firewalld:

# systemctl disable firewalld

To disallow starting firewalld manually as well, you can mask it:

# systemctl mask firewalld

Now you can enable iptables to start at the boot time by enabling iptables using systemctl command:

# systemctl enable iptables

How to check status of iptables in centOS 7

In previous distros, iptables status could be fetched using service command, although, the option is no longer available in CentOS 7. To fetch the iptables status, use the following:

# iptables -S

Iptables save command can still be used using service tool:

# service iptables save

This would save your iptables rules to /etc/sysconfig/iptables as it used to do in previous distros.

Linux: Assertion failed on job for iptables.service.

If you are using Centos 7 or RHEL 7 or any of it’s variant, you are probably using ‘Firewalld’ by default. Although, if you are a iptables fan like me, who likes it’s simplicity and manipulative nature instead of a full form firewall, then you probably have disabled firewalld from your CentOS 7 instance and using iptables. There are couple of servers, where I use runtime iptables rules for postrouting and masquerading. These rules are dynamically generated by my scripts instead of the sysconfig file under:

/etc/sysconfig/iptables

This file is generated upon running the iptables save command:

service iptables save

which I rarely do so.

Error Details

Which is why, I don’t have a /etc/sysconfig/iptables file in those servers and a common error I see while restarting iptables in those system is the following:

# systemctl restart iptables.service
Assertion failed on job for iptables.service.

How to Fix The Error

The error appears because you don’t have any rule in /etc/sysconfig/iptables or the file doesn’t exist either. You can ignore the error as iptables would still run. To eradicate the error, simply make sure you have some iptables rules loaded on your system using the status command:

iptables -S

And then, run:

service iptables save

Once done, restarting iptables shouldn’t show the error any longer.