Processes, services and remote access
Every running program is a process with a number (PID). ps and top show what is running, kill asks a process to stop, and systemctl manages the background services that systemd starts. ssh connects you to another machine securely, and df and du show where disk space has gone.
What is running?
Each running program is a process with a PID (process ID). ps -ef lists every process with its owner and the command that started it, so ps -ef | grep java finds Java processes. top (or the friendlier htop, where installed) shows a live view sorted by CPU use. Press q to leave it.
$ ps -ef | grep report asha 48211 1 12 10:20 ? 00:04:11 python3 report.py $ kill 48211 # polite: asks the process to finish (SIGTERM) $ kill -9 48211 # last resort: the system ends it at once (SIGKILL)
Plain kill sends SIGTERM, a request that lets the program close files and clean up. kill -9 sends SIGKILL, which the program cannot catch or refuse, so it gets no chance to tidy up. Use it only when a polite kill has not worked.
Services
Long-running background programs (web servers, databases, the Jenkins agent) are services. Most current distributions manage them with systemd, through the systemctl command. Their messages go to the systemd journal, which you read with journalctl.
| Command | What it does |
|---|---|
systemctl status nginx | Is it running, since when, and its last few log lines |
sudo systemctl restart nginx | Stop it and start it again |
sudo systemctl enable nginx | Start it automatically at every boot |
journalctl -u nginx --since "1 hour ago" | That service's log messages for the last hour |
Disk space
A full disk breaks builds in confusing ways. df -h shows how full each file system is, in human-readable units. du -sh * shows how much space each item in the current folder uses, so you can find the culprit, often an old log or a build cache.
ssh: working on another machine
ssh (Secure Shell) opens an encrypted session on a remote machine: ssh asha@build01.example.com. Instead of a password, most teams use a key pair. The private key stays on your machine, readable only by you (chmod 600). The public key is added to ~/.ssh/authorized_keys on the server. scp and sftp copy files over the same secure connection: scp release.tar.gz asha@build01:/tmp/.
Which command shows how full each file system is, in sizes such as 12G?
Show a hint
Two letters for disk free, plus the human-readable option.
Show the solution
df -h
Examples are for learning. Run commands and jobs only on a system you are authorised to use, such as a training or test system, and never on production without approval.
Common mistakes
The program cannot clean up, which can leave locks or half-written files. Try a plain kill first.
systemctl status and journalctl usually say why it stopped. A restart may hide the evidence.
ssh refuses to use a private key that other users can read. Keep it at chmod 600.
What you will see at work
- 'Is the agent running?' is answered with
systemctl statusorps -ef | grep agent, not by guessing. - Check
df -hearly when builds fail for no clear reason. A full disk is a classic cause. - Most teams log on to servers with ssh keys. Your first week often includes sending your public key to an administrator.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.