Some commands you can walk back. Terminating an EC2 instance is not one of them. Day 14 paired a recoverable problem, a web server knocked over by a rogue process, with an unrecoverable one, deleting a server on purpose, and the contrast is the whole lesson.
One Linux task, one AWS task. Track down the process blocking Apache and restore the service, then terminate an EC2 instance and confirm it is gone. The tasks come from the KodeKloud Engineer platform.
httpd: diagnose in order, then restore
When httpd will not start, resist the urge to guess. Work in order. Start with what the service itself reports:
# What does httpd think is wrong
systemctl status httpd
systemctl start httpd
The status output usually names the problem, and a failed bind on the port is the classic one. Before assuming a rogue process, check that httpd's own config is sane, because a wrong port or hostname produces the same "won't start" symptom:
# Check the configured listen port and server name
grep -i listen /etc/httpd/conf/httpd.conf
vi /etc/httpd/conf/httpd.conf
# Fix the ServerName directive if it is wrong: ServerName hostname:<port>
If the config is fine and the port is genuinely taken, then you go hunting for the process holding it:
# Find the PID on the conflicting port
sudo su -
yum install -y net-tools
netstat -tulpn
# Clear it, then bring httpd back
kill -9 <PID>
systemctl enable httpd
systemctl start httpd
systemctl status httpd
kill -9 is SIGKILL, the instant, no-cleanup kill. It is the right tool when a process is wedged and ignoring a polite request, but as a default habit, it is worth trying a plain kill first. The order that matters here is diagnostic: config before process, gentle signal before forceful one. Rushing to kill -9 at the first sign of trouble is how you mask the real cause instead of fixing it.
Terminating EC2: the command with no undo
Day 9 was about protecting an instance from termination. Day 14 is the other side of that lever, actually terminating one, on purpose:
# Terminate the instance
aws ec2 terminate-instances --instance-ids i-1234567890abcdef0
# Confirm the state moved to 'terminated'
aws ec2 describe-instances \
--instance-ids i-1234567890abcdef0 \
--query "Reservations[*].Instances[*].State.Name"
There is no recycle bin here. Once an instance is terminated, it and its instance-store data are gone for good. The thing worth checking before you run this is what happens to the storage. By default, the root EBS volume is set to delete on termination, so it goes with the instance. Extra volumes you attached usually survive, they detach instead of being deleted, but do not assume it. The DeleteOnTermination flag is set per volume, and you should know its value before you pull the trigger.
One quirk that confuses people. A terminated instance still appears in describe-instances for a little while, in the terminated state, before it disappears completely. That is normal, not a failed termination. And if this is a box you cannot afford to lose, that is precisely what Day 9's termination protection is for. Turn it on, and this command bounces instead of executing.
The contrast
The two tasks sit at opposite ends of reversibility. A downed web server is a puzzle you can take your time on, because nothing is lost while you diagnose. A termination is a decision you make once and cannot take back. Knowing which kind of action you are about to perform, recoverable or final, is what should change how carefully you move.
So here is the Day 14 question. Before you run a command, do you actually know whether you can undo it, or do you find out only when you try and can't?
Day 14 down. Eighty-six to go.
Top comments (0)