System Administration Basics
Check disk space and memory, read logs, manage services with systemctl, schedule jobs with cron, and manage users and groups.
On this page 11 sections
Introduction
Keeping a Linux machine healthy comes down to a handful of routine checks: is there enough disk space and memory, are the services running, what do the logs say, do scheduled jobs run, and who has access? This lesson covers the commands behind each of those questions — the everyday toolkit of system administrators, DevOps engineers and anyone who runs a server.
- How to check disk space, folder sizes and memory.
- Where logs live and how to read them.
- How to start, stop and enable services.
- How to schedule jobs with cron and manage users and groups.
Disk Space: df and du
df -h shows how full each disk (file system) is, in human-readable sizes:
df -h /Click Run to see what this code prints.
(This was recorded inside a container, whose disk is called overlay; on a normal machine you will see devices such as /dev/sda1 or /dev/nvme0n1p2, plus extra lines for other disks.) When a disk is filling up, du finds what is using the space; -s gives one total per item:
du -sh projects/*Click Run to see what this code prints.
du -sh * | sort -h lists everything in the current folder, smallest to largest. On servers, logs (/var/log), old backups and Docker images are the usual culprits.
Memory and Load
free -hClick Run to see what this code prints.
Look at the available column, not free: Linux deliberately uses spare memory as a disk cache (buff/cache) and hands it back the moment programs need it. Swap is disk space used as overflow memory; heavy swap use makes everything slow.
nprocuptimeClick Run to see what this code prints.
nproc counts CPU cores. uptime shows how long the system has run and the load average over 1, 5 and 15 minutes. A load roughly equal to the number of cores means the CPU is fully busy; much higher means work is queuing up.
Reading Logs
Traditional log files live in /var/log:
ls /var/logClick Run to see what this code prints.
Every package installation, for example, is recorded in dpkg.log:
grep " install " /var/log/dpkg.log | tail -n 3Click Run to see what this code prints.
On systems with systemd (Ubuntu, Debian, Fedora and most servers), many services log to the journal instead, read with journalctl:
| Command | Shows |
|---|---|
| journalctl -u nginx | Logs from one service |
| journalctl -u nginx -f | Follow new log lines live (like tail -f) |
| journalctl -p err -b | Errors since the last boot |
| journalctl --since "1 hour ago" | Recent entries only |
| tail -f /var/log/nginx/error.log | Follow an application’s own log file |
Managing Services
Services (also called daemons) are programs that run in the background permanently: web servers, databases, SSH, cron. On systemd systems you control them with systemctl:
| Command | What it does |
|---|---|
| systemctl status nginx | Is it running? Recent log lines and errors |
| sudo systemctl start nginx | Start it now |
| sudo systemctl stop nginx | Stop it now |
| sudo systemctl restart nginx | Stop and start (after changing its configuration) |
| sudo systemctl reload nginx | Re-read configuration without dropping connections, if supported |
| sudo systemctl enable nginx | Start it automatically at boot |
| sudo systemctl disable nginx | Do not start it at boot |
The older service command still works on Ubuntu and passes the request to systemd. It is also what works inside minimal environments such as containers, where this example was recorded:
sudo service cron startservice cron statusClick Run to see what this code prints.
You install a database, run sudo systemctl start postgresql, and it works. After the server reboots, the database is not running. Why?
Scheduling Jobs with cron
cron runs commands on a schedule — nightly backups, weekly clean-ups, reports every hour. Each user has a crontab (cron table). At first it is empty:
crontab -lClick Run to see what this code prints.
crontab -e opens your crontab in an editor. Each line has five time fields and then the command:
┌───────── minute (0-59)│ ┌─────── hour (0-23)│ │ ┌───── day of month (1-31)│ │ │ ┌─── month (1-12)│ │ │ │ ┌─ day of week (0-6, Sunday = 0)│ │ │ │ │0 2 * * * /home/priya/backup.sh /home/priya/projects >> /home/priya/backup.log 2>&1That line runs the backup script from lesson 12 at 02:00 every day and saves all its output to a log — essential, because cron jobs have no screen to print to. After saving, crontab -l confirms it:
crontab -lClick Run to see what this code prints.
| Schedule | Runs |
|---|---|
| */15 * * * * | Every 15 minutes |
| 0 * * * * | At the start of every hour |
| 30 2 * * * | Every day at 02:30 |
| 0 9 * * 1 | Every Monday at 09:00 |
| 0 0 1 * * | At midnight on the first day of each month |
cron runs with a very short PATH and no .bashrc, so commands that work in your terminal can fail there. Use full paths to scripts and programs, and always redirect output to a log file you can check.
Users and Groups
Give each person their own account rather than sharing one. Create a user with a home folder and Bash as their shell:
sudo useradd -m -s /bin/bash arjunid arjunClick Run to see what this code prints.
Set their password with sudo passwd arjun (on Ubuntu, the interactive sudo adduser arjun does all of this in one go). To let them use sudo, add them to the sudo group — -aG means append to a group, keeping their other groups:
sudo usermod -aG sudo arjungroups arjunClick Run to see what this code prints.
usermod -G sudo arjun (without -a) replaces all of arjun’s groups with just sudo, silently removing every other group membership.
Your website is slow. Put a sensible order of first checks together.
- uptime to see the load average
- free -h to check memory and swap
- journalctl -u nginx (or the app’s log) to look for errors
- df -h to make sure the disk is not full
- top to find the busiest processes
Common Mistakes
- Letting a disk fill to 100%, which can crash databases and stop logins — monitor df -h.
- Starting a service but not enabling it, so it does not come back after a reboot.
- Writing cron jobs without full paths or a log file, then never knowing they fail.
- Sharing one account between several people instead of creating individual users.
Frequently Asked Questions
Containers normally run a single program and do not start systemd. Inside them, services are run directly or with the service command; outside, on full servers and WSL with systemd enabled, systemctl is the standard.
Install updates regularly (apt upgrade), use SSH keys and disable password logins, run a firewall such as ufw allowing only the ports you need, give each person their own account, and keep backups.
Docker, which packages applications with everything they need to run anywhere, builds directly on these skills — and so does every cloud platform.
Key Takeaways
- df -h shows disk usage, du -sh finds what is big, free -h shows memory, uptime shows load.
- Logs live in /var/log and the systemd journal (journalctl).
- systemctl start/stop/restart/status manages services; enable makes them start at boot.
- cron runs scheduled jobs: five time fields, full paths and a log file.
- useradd/adduser create users; usermod -aG adds them to groups such as sudo.
Summary
Congratulations — you have completed Linux & Command Line. You can navigate and manage files, control permissions and processes, install software, automate tasks with scripts, work on remote servers and keep a system healthy. Put it all into practice with the course projects, then continue with Docker, where these skills meet modern application deployment.