DEV Community: Nagesh K

🔥 Automating Linux Tasks: Cron Jobs + Logging

Nagesh K — Tue, 07 Apr 2026 07:42:22 +0000

Automation is the backbone of DevOps, and cron jobs are one of the simplest yet most powerful tools for scheduling repetitive tasks in Linux. But here’s the golden rule : Never run cron without logs.
Without logs, you’re flying blind — you won’t know if your job succeeded, failed, or silently broke.

🕒 What is a Cron Job?
Cron is a time-based job scheduler in Unix/Linux.
It runs commands or scripts at specified intervals (minutes, hours, days).
Perfect for tasks like backups, monitoring, cleanup, or reporting.

✅ Example: Disk Usage Monitoring with Logging
Here’s a production-ready cron job:

*/5 * * * * /home/ubuntu/disk.sh >> /home/ubuntu/disk.log 2>&1
*/5 * * * * → Run every 5 minutes

/home/ubuntu/disk.sh → Script to check disk usage
>> /home/ubuntu/disk.log → Append standard output to log file
2>&1 → Redirect errors to the same log file
👉 This ensures both success and failure messages are captured.

🛡️ Why Logging Matters
Observability → Know what happened at each run.
Debugging → Errors are visible in logs.
Auditing → Historical record of job execution.
Reliability → Prevents silent failures.

⚡ Common Mistake: Typo in Service Name
A real-world example you might encounter:
ubuntu@ip-172-31-39-174:~/shell-script-learnings$ sudo systemctl stop corn Failed to stop corn.service: Unit corn.service not loaded.
👉 The error happened because the service name is cron, not corn.
Correct command:

sudo systemctl stop cron
sudo systemctl start cron
sudo systemctl status cron

📝 Managing Cron Jobs

1. Add a Cron Job
crontab -e : Paste your job line, save, and exit.

2. List Current Cron Jobs
crontab -l

3. Remove a Specific Cron Job
Open crontab: crontab -e
Delete the line corresponding to the job, Save and exit.

4. Delete All Cron Jobs
crontab -r
⚠️ This wipes the entire crontab for the user.

🚀 Production Enhancements

Timestamps in logs:
*/5 * * * * echo "$(date) - Running disk.sh" >> /home/ubuntu/disk.log 2>&1; /home/ubuntu/disk.sh >> /home/ubuntu/disk.log 2>&1
Log rotation (prevent infinite growth):
Create /etc/logrotate.d/disk:
Code:

/home/ubuntu/disk.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 644 ubuntu ubuntu
}

🎯 Conclusion
Cron jobs are deceptively simple but incredibly powerful. The difference between a hobby script and a production-grade job is logging and management.
Always log output and errors.
Monitor logs with rotation.
Manage jobs cleanly with crontab -e, crontab -l, and crontab -r.

Understanding Script vs Function Arguments in Bash

Nagesh K — Fri, 03 Apr 2026 04:07:08 +0000

When writing shell scripts, one of the most common sources of confusion is positional parameters — the $1, $2, $3 variables that represent arguments passed to a script or function. Let’s walk through a real example to make this crystal clear.

The Script:

#!/bin/bash

backup(){
    backup_name="${1}_$(date +%F_%H-%M-%S).tar.gz"
    if tar -czf "$backup_name" "$1"; then
        echo "✅ Backup created: $backup_name"
    else
        echo "❌ Backup failed for $1"
    fi
}

list(){
    find . -type f -name "*.tar.gz"
}

case $1 in
    back)
        backup "$2"
        ;;
    list)
        list
        ;;
    *)
        echo "Usage:"
        echo "  $0 back <directory_or_file>"
        echo "  $0 list"
        ;;
esac

How It Works
Step 1: Script Arguments
When you run:
./backup-manager.sh back dir21
$0 → ./backup-manager.sh (the script name)
$1 → back
$2 → dir21
The case statement checks $1. Since it’s back, the script calls:
backup "$2"

Step 2: Function Arguments
Now the function backup() is called with one argument: dir21.
Inside the function:
$1 → dir21 (because $1 inside a function refers to the first argument passed to that function, not the script’s $1 anymore).
That’s why you see $2 in the script but $1 inside the function — they’re different scopes.

Example Run

$ ./backup-manager.sh back dir21
✅ Backup created: dir21_2026-04-03_09-25-00.tar.gz

$ ./backup-manager.sh list
./dir21_2026-04-03_09-25-00.tar.gz
Key Takeaways
Script arguments ($1, $2, …) are what the user types after the script name.
Function arguments ($1, $2, … inside the function) are what you pass when calling the function.
They are independent: $1 in the script is not the same as $1 inside the function.

Bonus Tip: Multiple Backups
You can extend the script to back up multiple directories at once:

case $1 in
    back)
        shift   # remove "back" from arguments
        for target in "$@"; do
            backup "$target"
        done
        ;;
    list)
        list
        ;;
    *)
        echo "Usage: $0 back <dir1> <dir2> ... | $0 list"
        ;;
esac

Now you can run: ./backup-manager.sh back dir21 dir22 dir23
and it will back up all three.

💡 This is a great example to blog about because it shows the layered nature of arguments in Bash — script level vs function level — and clears up a common beginner confusion.

Git Push Rejected: Understanding and Fixing Common Errors

Nagesh K — Thu, 02 Apr 2026 14:21:02 +0000

When working with Git, one of the most common frustrations developers face is the dreaded push rejected error. This usually happens when your local branch is out of sync with the remote branch. Let’s break down why this occurs and how to fix it.

Why Does Git Reject a Push?
Git prevents you from overwriting changes that exist on the remote but not in your local branch. This ensures that you don’t accidentally erase someone else’s work or lose commits. The error message often looks like this:

! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://github.com/...'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally.

Common Fixes

1. Rebase (Recommended) : If you want to keep a clean, linear history:

git pull origin main --rebase
# resolve conflicts if any
git rebase --continue
git push origin main

This approach reapplies your local commits on top of the remote branch.

2. Merge : If you don’t mind merge commits:

git pull origin main
# resolve conflicts if any
git push origin main

This creates a merge commit combining both histories.

3. Force Push (Dangerous) : If you want to overwrite the remote branch entirely:
git push origin main --force
⚠️ Warning: This will erase remote commits not present locally.

What About --allow-unrelated-histories?
This option is used when two repositories don’t share a common history (e.g., you initialized locally and then connected to a remote with its own commits). It forces Git to merge unrelated histories. In most cases, you don’t need this if your local and remote already share a history.

Best Practices:
Use rebase for a clean history.
Use merge if you prefer explicit merge commits.
Avoid force push unless you’re absolutely sure.
Reserve --allow-unrelated-histories for truly separate repositories.

Conclusion
A rejected push isn’t a blocker—it’s Git protecting your project’s history. By understanding when to rebase, merge, or force push, you can resolve these errors confidently and keep your repository healthy.

Git Clone vs Remote Add: The Battle of First Steps

Nagesh K — Wed, 25 Mar 2026 03:23:28 +0000

When you’re new to Git, one of the most confusing questions is:
Should I use git clone or git remote add origin … + git pull?

Let’s make this fun and crystal clear.
🖥️ git clone: The One-Click Magic
Think of git clone as the “Download Project” button.

When you run:
git clone https://github.com/company/project.git

Git does all the heavy lifting for you:

Creates a new folder named project.
Runs git init inside it.
Connects the remote (origin).
Pulls down all files + commit history. 👉 In one shot, you have a fully working project folder ready to explore.

📂 git remote add origin … + git pull: The Manual Way
This is more like building your own workspace from scratch.

Steps look like this:

mkdir myrepo && cd myrepo
git init
git remote add origin https://github.com/company/project.git
git pull origin main

Here, you:

Create the folder yourself.
Initialize Git manually.
Tell Git where the remote is.
Finally, pull the files. 👉 It works, but it’s extra steps.

🎯 The Shortcut vs The Long Road

git clone → Best when you just want the project as-is. Quick, clean, automatic.
remote add + pull → Best when you already created a repo locally and now want to connect it to a remote.

💡 Imagine it like this:
Clone = “Download the whole project in one click.”
Remote add + pull = “I made an empty folder, now let me link it and fetch files.”

📝 Bottom Line
If you’re a new user who wants the same project folder from GitHub, always use git clone.
The manual method is only for special cases when you’ve already set up a repo locally.

🔥 Next time you see a cool project online, just remember:
Clone it, don’t complicate it.

Day -2 : Essential Linux File System Knowledge for DevOps Engineers.

Nagesh K — Mon, 23 Mar 2026 16:20:56 +0000

As a DevOps engineer, understanding the Linux file system is non‑negotiable. It’s the foundation of where you store code, configure services, check logs, and deploy applications. In this post, I’ll walk you through the most important directories, their purposes, and how you should use them in daily DevOps work.

🏠 User Workspaces vs System Areas

User workspace (/home/): This is where you should keep your project code, scripts, and personal files. For example, if your username is ubuntu, your workspace is /home/ubuntu.
System areas (/etc, /var, /usr, etc.): These directories are reserved for configurations, logs, binaries, and deployments. You’ll often need sudo to work here because they affect the whole system.

📂 Key Directories Every DevOps Engineer Must Know
/home/
Purpose: User’s personal workspace
DevOps Usage: Store project code, scripts, configs
Example Commands:
cd ~ cd /home/ubuntu

/root
Purpose: Root user’s home directory
DevOps Usage: Reserved for admin tasks, not coding
Example Commands:
sudo su - cd /root

/etc
Purpose: System configuration files
DevOps Usage: Manage service configs (Nginx, SSH, systemd)
Example Commands:
cd /etc/nginx nano /etc/ssh/sshd_config

/var/log
Purpose: System and application logs
DevOps Usage: Debug services, monitor errors
Example Commands:
tail -f /var/log/syslog less /var/log/nginx/error.log

/var/www
Purpose: Web server files
DevOps Usage: Deploy websites and applications
Example Commands:
cd /var/www/html
git clone

/usr/bin
Purpose: User binaries (commands available to all users)
DevOps Usage: Run system commands like ls, grep, etc.
Example Commands:
ls /usr/bin

/bin
Purpose: Essential binaries for boot and recovery
DevOps Usage: Core commands like cat, cp, mv
Example Commands:
ls /bin

/sbin
Purpose: System binaries for admin tasks
DevOps Usage: Commands like shutdown, mount
Example Commands:
ls /sbin shutdown -h now

/opt
Purpose: Optional software packages
DevOps Usage: Install custom tools or third‑party apps
Example Commands:
cd /opt

/tmp
Purpose: Temporary files (cleared on reboot)
DevOps Usage: Scratch space for testing or temporary storage
Example Commands:
cd /tmp

/dev
Purpose: Device files
DevOps Usage: Interfaces to hardware (disks, terminals)
Example Commands:
ls /dev/sda ls /dev/tty

/proc
Purpose: Virtual filesystem with process and kernel info
DevOps Usage: Check CPU, memory, and process details
Example Commands:
cat /proc/cpuinfo cat /proc/meminfo

/mnt and /media
Purpose: Mount points for external drives
DevOps Usage: Access USBs, external disks
Example Commands:
cd /mnt ls /media/ubuntu

One‑liners for each directory (quick reference).
/home → user workspace /root → root’s home /etc → configs /var/log → logs /var/www → web apps /usr/bin → user binaries /bin → essential binaries /sbin → admin binaries /opt → optional software /tmp → temporary files /dev → devices /proc → process info /mnt,/media → mount points

⚙️ Best Practices for DevOps Work

Workspace: Keep your project repos inside /home/ubuntu.

Example: mkdir myproject && cd myproject && git init
System Configs: Edit service configs in /etc using sudo.

Example: sudo nano /etc/nginx/nginx.conf
Logs: Monitor logs in /var/log for debugging.

Example: tail -f /var/log/syslog
Deployments: Place production code in /var/www.

Example: sudo git clone <repo> /var/www/html
Installations: Use sudo apt install … — packages go into /usr/bin, /usr/lib, etc.

Scratch Work: Use /tmp for temporary files.

📝 Conclusion
For a DevOps engineer, knowing the Linux file system is like knowing the map of a city. You need to know where to live (/home), where the government offices are (/etc), where the logs are kept (/var/log), and where the factories produce tools (/usr/bin). Once you master this structure, you’ll navigate servers confidently, troubleshoot faster, and deploy with precision.

Git -> Quick Drill Sheet

Nagesh K — Sun, 22 Mar 2026 16:38:40 +0000

Important concepts you understood:
Working Directory 👉 Where you edit files
Staging Area 👉 Temporary place before commit
Commit 👉 Snapshot of project
Local Repository 👉 Git history on your machine
Remote Repository 👉 GitHub copy of your project

Git Workflow (Most Important) : Always remember this pipeline.
Working Directory
↓
git add
↓
Staging Area
↓
git commit
↓
Local Repository
↓
git push
↓
GitHub

Faster shortcut (useful for single file edits)
git commit -am "updating git_notes.txt"
Reason: -a automatically stages modified files (not new files).

Topic	Key Command
Repository files	`ls`
Create files	`echo "text" > file`
Read file	`cat file`
Initialize git	`git init`
Global config	`git config --global user.name "Alice"`
Global config	`git config --global user.email "mail.com"`
Check repo status / See modified, staged, and branch info	`git status`
Staging area	`git add file` / `git add .`
Undo staging	`git reset file`
add remote origin	`git remote add origin <repo-URL>`
Commit changes	`git commit -m "message"`
Push to GitHub	`git push -u origin main`
Pull from GitHub	`git pull origin main`
Merge repos with different histories	`git pull origin main --allow-unrelated-histories`
View commit history	`git log`
Short commit history	`git log --oneline`
File-specific history	`git log -- filename`
Repository connection	`git remote -v`
Cloning a repo	`git clone <repo-URL>`
Branch info	`git branch`
Delete empty files	`find . -type f -empty -delete`
Delete files in Git	`git rm file` + `git commit`
create + switch branch	`git checkout -b <branch name>`
Switch branches(new way)	`git switch branchname and git switch -c newbranch`
Branch info	`git branch` => * feature1 , main
delete Branch	`git branch -d <name>`

Core workflow you practiced
Edit file
↓
git add .
↓
git commit -m "message"
↓
git push

Branching Strategy :-

------ CODE REVIEW HAPPENS HERE ------
Pull Request → reviewers check code → CI tests run → approval

git checkout main | switch to main branch
git merge newfeature | merge the newfeature to main branch
git push origin main | to get updated content
git branch -d newfeature | delete the feature branch

Real World vs Theory Lessons

Nagesh K — Sun, 22 Mar 2026 16:02:17 +0000

In theory, checking disk usage looks simple — just grab the percentage from df -h. But in the real world, scripts break, formats differ, and human‑readable values like 374G don’t compare cleanly. This post is about the lessons learned when theory meets reality.

Disk Usage Monitoring in Linux: Percentage vs. Actual Size

Monitoring disk usage is one of the most common tasks for system administrators and developers. But there’s often confusion between checking percentage usage (df -h) and checking actual disk space (du -sh with numfmt). Let’s break down the challenges, solutions, pros, and cons of each approach.

❓ Common Questions
Should I monitor disk usage by percentage or by actual size?
Why does my script fail with “integer expression expected” errors?
How can I compare human‑readable sizes like 192K, 374G, or 2T against thresholds?
Which method is more reliable across different environments (Linux, Git Bash, macOS)?

⚡ The Challenge
Using df -h with percentages
A typical script might look like this:

disk_usage=$(df -h | awk 'NR>1 {print $5}' | sed 's/%//')
for usage in $disk_usage; do
    if [ "$usage" -gt 70 ]; then
        echo "Warning: Disk usage is high ($usage%)"
    else
        echo "Disk usage is normal ($usage%)"
    fi
done

Problem:
Sometimes df -h outputs values like 374G in other columns.
If parsing isn’t precise, your script may grab 374G instead of 22%.
[ -gt ] only works with integers, so 374G causes integer expression expected errors.

Using du -sh with numfmt
A more robust approach is to normalize values into bytes:

size=$(du -sh | awk '{print $1}')
bytes=$(numfmt --from=iec "$size")
threshold=$(numfmt --from=iec 100G)

if [ "$bytes" -gt "$threshold" ]; then
    echo "Disk usage is high: $size"
else
    echo "Disk usage is normal: $size"
fi

Here:
du -sh → gives human‑readable size (192K, 374G, etc.).
numfmt --from=iec → converts those into raw integers (bytes).
Thresholds like 100G, 500M, 2T are also converted into bytes.
Comparisons are now reliable and portable.

✅ Solutions
For percentage checks: Use df -h | awk 'NR>1 {print $5}' | sed 's/%//' to extract only numeric percentages.

For actual size checks: Use du -sh + numfmt to convert human‑readable values into integers.

Hybrid approach: Monitor both percentage and actual size for a complete picture.

📊 Pros and Cons

🚀 Conclusion
If you just want a quick warning when usage exceeds 70%, percentage checks with df -h are fine.
If you need robust monitoring across environments, or want to enforce thresholds like “alert me if usage exceeds 100G,” then numfmt is the best choice.
In real production scripts, combining both methods gives the most reliable monitoring.

My Cloud and DevOps Journey : Day 1

Nagesh K — Sun, 22 Mar 2026 15:47:56 +0000

Start From Linux with Shell Scripting for DevOps :

Shell scripting is like learning a new language — at first, the syntax feels cryptic, but every small win builds confidence. Over time, I’ve discovered not just commands, but ways of thinking about automation, problem solving, and DevOps workflows. Here’s a reflection on the lessons, challenges, and insights I’ve gathered so far.

Early Lessons Learned

File and Directory Operations
Use find when you need to search across directories.
Use [ -f ] when you already know the exact path you want to check.
:> filename → resets a file to empty without deleting it.
exit 1 → stops the script at the failure point.
echo $? → inspects the exit code of the last command.
👉 These basics taught me how to control flow and handle files safely.
Conditional Logic
[ ] → used for conditions (strings, files, etc.).
[[ ]] → more powerful, supports pattern matching.
(( )) → used for arithmetic comparisons.
Commands can run directly in if without [ ].

/dev/null → suppresses normal output.
2>&1 → suppresses error messages too.

Challenge: Forgetting spaces inside [ ] caused errors like “command not found”. Lesson: Always put spaces around brackets.

🔄 Loops: Thinking in Iterations
🛠️ How to Think About Loops
For loop → “Do this for each item.” (fixed list or range).
While loop → “Keep doing this until the condition fails.”
Until loop → “Keep doing this until the condition succeeds.”
Array loop → Use "${array[@]}" with for because you know the items.

🔄 Types of Loops in Shell

For Loop

for i in {1..5}
do
  echo "Number: $i"
done

Use case: Iterating over files in a directory.

for file in *.txt
do
  echo "Processing $file"
done

While Loop

count=1
while [ $count -le 5 ]
do
  echo "Count: $count"
  count=$((count+1))
done

Use case: Monitoring a service until it starts.

Until Loop

bash
count=1
until [ $count -gt 5 ]
do
  echo "Count: $count"
  count=$((count+1))
done

Infinite Loop

while true
do
  echo "Running..."
  sleep 2
done

Use case: Continuous monitoring tasks.

Rule of Thumb
Inside loops:
for file in *.sh → no need for [[ ]].
Use [[ ]] for string/pattern conditions.
Use (( )) for numeric conditions.
Outside loops: same rule applies.

Best Example:

#!/bin/bash
for file in *
do
    if [[ $file == *.sh ]]; then
        echo "Shell script: $file"
    fi
done

⚙️ DevOps Connection
For loop + [[ ]] → Iterate files and check extensions, permissions, or patterns.
For loop + (( )) → Iterate numbers (like retries, ports, IDs).
While loop → Monitor service status or retry logic.
Until loop → Wait until a condition succeeds (e.g., deployment ready).

🧩 Challenges We Faced
Parsing errors: Forgetting spaces in [ ].
Percentage vs actual size: df -h vs du -sh.
Suppressing output: Learning >/dev/null 2>&1.
Exit codes: Understanding how echo $? helps debug scripts.

✅ Key Takeaways
Think in conditions: [ ] for files/strings, [[ ]] for patterns, (( )) for numbers.
Think in loops: For known ranges → for; for monitoring → while; for waiting → until.
Normalize values: Use numfmt to convert human-readable disk sizes into integers.
Fail fast: Use exit 1 to stop at the failure point.
Debug smartly: Use echo $? to check exit codes.