Hi folks!

Good morning!

How are you all doing today, my friends?

Let’s get started with our Kode Kloud DevOps learning and some hands-on practice task, from our good friends at Kode Kloud.

We give our thanks.

For this chance to keep learning. To grow our skills.

Okay.

For today, we have this task from our web-interface briefing.

My brothers and sisters, please look at “Day 14 – Linux Process Troubleshooting” from the following:

First off, let’s have some coffee goodness. ☕

Caffeine ⚡ helps during the morning, my friends. Yes?

Let’s make coffee(s) ☕, not war(s) 💥 – okay, folks?

Peace be with you all ☮️, my dear brothers and sisters in Christ 🕊️.

---

Folks, please pardon me for this, but, before I can continue writing this post for today – I need to work on our laboratory exercise first – okay?

I need to do it differently this time, I’m sorry.

If you look at my previous posts from the past recent weeks. What I did there was to write ’em posts while doing our laboratory practice tasks at another side. It isn’t conducive, also, it’s a disservice to you readers and fellow-learners, because my posts are lousy, and the details suffer.

With this, I’m going to make some changes to how I write our posts here.

One, I need to do the practice laboratory first, hopefully finish it and for me to get past the task-checkers. Only after this, can I continue on writing our post for the day.

Doing it this way, is helpful. I can focus on the task, it also helps with my own learning journey (again, I don’t know it all, alright folks?).

For now, I’ll head over to our web-interface where we can work on our task for the day. Okay? I’ll see you folks later. Well – that’s if I can get it right. Hehe. 😆

Thanks, take care – that’s it for now.

God bless. 🙌

---

Continuation – September 15, 2025

Hi! Hey folks!

It’s already Monday lunch-time (from our local time over here), 15th of September.

How are you?

Friends, let’s continue going forward with our task from Day 14 out of 100 Days of DevOps. Alright?

Okay.

We have the following task briefing from our folks at Kode Kloud:

The production support team of xFusionCorp Industries has deployed some of the latest monitoring tools to keep an eye on every service, application, etc. running on the systems. One of the monitoring systems reported about Apache service unavailability on one of the app servers in Stratos DC.

Identify the faulty app host and fix the issue. Make sure Apache service is up and running on all app hosts. They might not have hosted any code yet on these servers, so you don’t need to worry if Apache isn’t serving any pages. Just make sure the service is up and running. Also, make sure Apache is running on port 8084 on all app servers.

Okay.

According to our task briefing: we have one server (we don’t know which of the 3 app servers) that has an Apache service not running.

We’ll need to check each one, my friends.

We begin with our web app server01.

SSH into our web app server 01 with this Linux command:

ssh tony@stapp01

Okay, we’re in.

Good work, my friends.

Hmm. Folks, if you need to bring up our infrastructure details. Please look over this table over here:

We check our Apache web service status (process known as “httpd”).

Remember to escalate privileges into “root”.

sudo su -

As, we will need to do some checking and if necessary some troubleshooting of a system service.

If we don’t escalate our privileges. Sorry, we won’t be able to do our task. Linux won’t let you. Root privileges means administrator access.

Okay.

Let’s continue working together, my friends.

We check httpd (Apache web server) status currently, with this one:

systemctl status httpd

And we have the following print out.

What this text from our command-line interface is telling us: is that our Apache service (httpd) is encountering an issue, and fails to start.

systemctl status httpd -l

We do that status check request once more, but, this time, we ask Linux to be more “verbose” with the error print out.

This way, we will have more information about the error.

It helps with our troubleshooting and fix attempt.

Folks, if you read the error stream. It tells us that our Apache process is encountering a port conflict issue.

Which could mean that something else is utilizing a defined port we need Apache to do its work from.

Okay.

And now, before checking for that – we first need to verify if Apache (httpd) is set or configured to utilize port “8084”, as said from our task briefing.

We invoke Apache’s configuration file.

sudo vi /etc/httpd/conf/httpd.conf

And find that Apache’s configuration file has a pre-existing definition to work on port number “8084”.

We exit our text editor program. Enter “esc” followed with keys “:q” for quit program.

And continue our troubleshooting task.

From our httpd status check, we determined that something else, another system program is using the same port “8084” that Apache needs to work.

We try to investigate a little with our internal connectivity, with the following.

sudo netstat -tulpn | grep 8084

My friends, this Linux command invokes a program called “netstat” to look for anything that listens, or utilizes port number “8084”.

What we find, is that there is another program component that’s already listening on port number “8084”.

We need to know further. So we dig a little further. With the following:

ps aux | grep sendmail

This Linux command asks the system to display processes currently running relating to a program called “sendmail”.

We need to look further, because we found that a component of sendmail is using port 8084.

From the program output, we find that a process ID (number 776) is listening on port 8084.

We must quit that process – to free up port number 8084, for our Apache web server.

sudo kill 776

This forces Linux to quit or shutdown the process ID 776. And frees up port number “8084”.

After verifying that port “8084” is now free.

We must ask Linux to restart our Apache web service.

systemctl restart httpd

After checking if Apache web server is now properly running or functioning.

systemctl status httpd

Okay, now we have Apache web service running properly on our web server 01. Good job, folks!

Next.

We need to determine if our other web app servers (steve@stapp02 and banner@stapp03) have their Apache web services running well.

SSH into server 02:

ssh steve@stapp02

Access administrator “root” privileges:

sudo su -

Then, input this Linux command on each server, so that we can determine how’s their Apache service doing.

systemctl status httpd

Repeat the Apache status request for server 03.

Finally, SSH into server 03.

ssh banner@stapp03

Enter administrator mode through this one:

sudo su -

Then, invoke a status check for our Apache service.

systemctl status httpd

Okay.

Good work so far, team! 🙂

To do a recap:

---

After doing needed troubleshooting, we have our Apache web service back up and running on our server 01. We also checked that the same web service (Apache) is running well from servers 02 and 03.

I think that’s it, my friends.

We ask Kode Kloud to check our work.

---

Cool beans!! 🫘

We’ve done our Day 14 task!

Congrats, folks! 🙂

See you all next time, alright?

God bless.