I have been working with Linux and infrastructure for many years, and one thing that has remained common in my day-to-day work is troubleshooting.
A Linux administrator or DevOps engineer can spend a lot of time running commands, checking logs, looking at CPU and memory usage, checking disk space, verifying services and then trying to understand what all that information means.
Most of these commands are not difficult.
The difficult part is sometimes connecting all the information together and finding where the actual problem is.
This made me think about a simple idea:
Can I use an AI model to assist with Linux troubleshooting directly from the command line?
Instead of building another web-based chatbot, I wanted to keep it simple.
So I created a small Bash-based Linux/DevOps AI Assistant script using Ollama AI Cloud model.
The idea is not to allow AI to control the Linux server. The idea is to let AI help the System administrator collect the right information, analyse it and explain the possible issue.
The basic architecture
The Bash script acts as the middle layer between the Linux system and the AI model.
It reads the user’s question, sends it to Ollama, receives the model’s response and, when required, allows the model to request an approved Linux diagnostic command.
The script uses curl to communicate with the Ollama API and jq to construct and process the JSON messages. The model is defined in the script and API key are supplied through environment variables.
What problem am I trying to solve?
Consider a normal Linux troubleshooting situation.
Someone reports:
The server is slow.
As an administrator, I may start checking:
uptime
free -h
df -h
ps aux –sort=-%cpu | head -20
ps aux –sort=-%mem | head -20
ss -tulpn
Then I may check services:
systemctl status nginx
And logs:
journalctl -u nginx -n 50
The commands themselves are simple.
But the administrator still has to decide:
Which command should I run next?
That is where I wanted to experiment with AI.
Instead of asking the AI:
Tell me what command I should run.
I wanted to allow the AI to actually request diagnostic information from the Linux system.
The AI does not directly control Linux
This was one of the most important parts of the design.
I did not want to build something where the AI could simply generate:
rm -rf /
and Bash executes it. That would be a very bad idea.
Instead, the model gets access to one controlled tool:
run_linux_diagnostic
The purpose of this tool is clearly defined as running an approved read-only Linux diagnostic command.
The AI can request a command. But Bash decides whether that command is allowed. So the model is not getting unrestricted shell access.
How command validation works
The script has a validate_command() function.
It contains an allowlist of diagnostic commands such as:
uptime
uname -a
df -h
free -h
ps aux –sort=-%cpu | head -20
ps aux –sort=-%mem | head -20
ss -tulpn
du / -chx –max-depth=1
du -sh /var/*
du -sh /tmp/*
It also allows controlled forms of:
systemctl status <service>
and:
journalctl -u <service> -n 50
These are all intended for information gathering rather than changing the system.
The script also tells the model not to request destructive or state-changing operations such as:
rm
mv
chmod
chown
kill
reboot
shutdown
systemctl restart
systemctl stop
The system prompt specifically instructs the model to use diagnostic tools when actual system information is required and not to assume the problem before checking the system.
Let’s take a real example
Suppose I run the Agentic AI Linux diagnostic bash script and ask:
You: Why is my server running out of disk?
The Agentic AI Bash script adds my question to the conversation history and sends the request to Ollama. The model can decide that it needs actual disk information.
It can request:
df -h
The Agentic AI Bash script receives the tool request.
Before running anything, it checks:
Is df -h allowed?
The answer is yes.
Bash executes the command.
The output could be:
Filesystem Size Used Avail Use%
/dev/sda2 100G 94G 6G 94%
The result is then sent back to the AI model. Now the model has actual information from the server. It may decide that it needs to know which directory is consuming the space.
It could request:
du -sh /var/*
Again Bash validates it.
If it is allowed, the command runs. The result goes back to the model. Now the AI can explain the situation based on actual server information instead of giving a generic Linux troubleshooting answer.
For example:
The filesystem is 94% full.
The next area to investigate is /var because it may
contain large log files, package caches or application data.
I would check the largest directories before taking any cleanup action.
This is the part I find interesting. The AI is not just answering a question. It is participating in the diagnostic process.
Another example — high CPU usage
Suppose I ask:
You: My Linux server is showing high CPU usage. Can you investigate?
The AI may need information about the current processes.
It can request:
ps aux –sort=-%cpu | head -20
The script allows this command and executes it.
The output may show:
USER PID %CPU %MEM COMMAND
appuser 2314 92.4 4.2 java …
root 1452 11.3 0.5 …
The AI now has actual information about the server.
Instead of simply saying:
Check the CPU usage.
it can explain that a particular process is consuming a large percentage of CPU and suggest what should be investigated next.
This is more useful to an administrator because the answer is based on current system data.
Memory troubleshooting
The same concept can be used for memory issues.
For example:
You: Check whether memory could be causing the performance problem.
The AI can request:
free -h
and potentially:
ps aux –sort=-%mem | head -20
The first command gives an overview of memory usage. The second helps identify processes consuming the most memory. The AI can then correlate the information and explain what it sees.
Again, the important point is that Bash is collecting the data and Ollama is helping interpret it.
Service troubleshooting
This becomes even more useful when troubleshooting services.
Suppose I ask:
You: Check the status of nginx.
The model can request:
systemctl status nginx
If the service is not running or has failed, the next useful information could be the recent logs:
journalctl -u nginx -n 50
The script supports this controlled service-status and journal pattern.
The AI can then explain the output.
For example, instead of the administrator manually going through several screens of logs, the assistant can summarize the important information and explain what should be investigated next.
The important part is the feedback loop
The core of this project is not the Bash chat interface.
It is this loop:
The script implements this as an agent loop.
When Ollama returns a tool call, Bash extracts the requested command, validates it, executes it if allowed, and adds the result back into the conversation. If there is no tool call, the assistant treats the response as the final answer.
That is what makes this different from a simple:
Question → AI → Answer chatbot.
AI-Assisted Web Service Issue Diagnosis Demo
Watch the Agentic AI Linux Troubleshooter diagnose a web service issue using AI-driven reasoning, Bash-based diagnostics, and real-time system information.
Watch the Demo on YouTube
Conversation history
Another useful part of the script is that it maintains conversation history. The messages are stored in a JSON structure using jq.
So I can start with:
You: My server is slow.
Then:
AI: I need to check CPU and memory.
Then:
You: CPU looks normal.
And continue the conversation without starting from zero every time. The script also provides a clear option to reset the conversation history.
This is useful because Linux troubleshooting is usually not a single question and answer.
It is a conversation:
What is wrong?
↓
Check something
↓
What did we find?
↓
Check something else
↓
What does that tell us?
Why use AI for this?
Linux administrators already know these commands.
So why use AI?
I don’t see this as replacing the Linux administrator.
The administrator still needs to understand Linux.
The value is in reducing some of the repetitive work around troubleshooting.
For example, an experienced administrator may already know:
High CPU → ps
Memory → free / ps
Disk → df / du
Service → systemctl
Logs → journalctl
Network → ss
But the AI can help with the next layer:
What should I check first?
What does this output mean?
What should I investigate next?
Are these two symptoms related?
Can you explain this output in simple terms?
That can be particularly useful when troubleshooting an unfamiliar application or server.
Why Bash instead of Python?
I could have built this in Python.
In fact, Python would probably make some parts easier.
But I deliberately wanted to keep the first version simple.
Linux already has Bash.
Most Linux administrators already know how to execute commands from Bash.
The AI doesn’t need to replace the existing Linux tools.
It can sit on top of them.
The stack is very small:
Linux
Bash
curl
jq
Ollama
The script itself also keeps the responsibilities fairly clear:
Ollama
↓
Reasoning
Bash
↓
Validation + execution
Linux
↓
Actual system information
Where I see this helping a DevOps administrator
I see several practical use cases.
Linux server troubleshooting
CPU
Memory
Disk
Processes
Services
Logs
Network
Application troubleshooting
For example:
Is the service running?
Is the port listening?
What are the recent service logs?
Is the system under resource pressure?
Incident investigation
During an incident, an administrator can ask the assistant to collect specific diagnostic information and explain the results.
Instead of manually remembering every command, the assistant can help drive the investigation.
On-call support
This could also be useful for engineers who are less familiar with a particular Linux environment.
The AI can explain the diagnostic output while still using the standard Linux commands underneath.
But I would not allow AI to fix everything automatically
This is another important point.
There is a big difference between:
Diagnose
and:
Change the system
I am comfortable experimenting with:
df -h
free -h
ps
systemctl status
journalctl
ss
du
because these are primarily information-gathering operations.
I would be much more careful with:
systemctl restart
rm
kill
chmod
chown
reboot
because these can change the state of the system. That is why I have kept the first version focused on read-only diagnostics. The AI can help identify the problem. The engineer can decide what action should be taken.
What I learned from building this
For me, the interesting part of this project is not simply connecting Bash to an AI model.
The interesting part is deciding where AI should be used and where existing automation should remain in control.
Linux already has powerful diagnostic tools.
Bash already knows how to execute them.
Ansible already knows how to automate configuration.
Terraform already knows how to manage infrastructure.
Cloud CLI tools already know how to interact with cloud platforms.
I don’t think we need AI to replace all of these.
Instead, AI can provide another layer on top:
AI
Understanding
Reasoning
Explanation
↓
Existing automation
↓
Infrastructure
That is the direction I find more practical.
Wrap Up !
This started as a simple experiment:
Can I build a Linux AI assistant using Bash and Ollama?
The answer is yes.
But the more interesting outcome is what happens when the AI is allowed to interact with the system in a controlled way.
The Bash script becomes the bridge between:
Human
↓
AI
↓
Bash
↓
Linux
The AI can understand the question and decide what information it needs.
Bash can validate the requested operation.
Linux provides the actual data.
And then the AI can explain what that data means.
For me, this is a more practical way of looking at AI in Linux and DevOps.
The goal is not to replace the administrator.
The goal is to reduce the repetitive work around the administrator and make troubleshooting easier.
This is still a small proof of concept, but I think the same architecture can be extended towards Ansible, Azure, AWS, Kubernetes and existing DevOps automation.
That is where I would like to take this project next.
Charanjit is passionate about automating tasks and improving processes. He uses tools like Terraform and Azure DevOps to build and manage cloud infrastructure and streamline deployment. He also enjoys using Shell scripts and Ansible playbooks to make systems run more efficiently.
In his free time, Charanjit enjoys learning about new technologies and sharing his knowledge through his blog. When he’s not working, he likes listening to music, having a cup of coffee, and relaxing in nature.
You can connect with Charanjit on Twitter, Facebook, LinkedIn, or email him at charanjit.cheema@cjcheema.com.