Linux Package and Service Management
Install software, manage repositories, and control systemd services and boot targets reliably.
- Certification
- CompTIA Linux+
- Recommended study time
- 5h 35m
- Status
- Not started
Recommended study time
About 5h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 8 sittings.
- Read the lesson22 min
About 2,868 words at a careful technical reading pace.
- Second pass with notes13 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice2h 40m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 20m
4 short review sessions spread over the following weeks.
Learning objectives
- Use apt and dnf safely including updates, removal, and repository control.
- Manage systemd units for start, enable, dependency, and failure behaviour.
- Diagnose a failed service using journal output and unit status.
Start here
About 8 minutes of reading, in 10 short parts.
A Linux server is really just a base operating system plus whatever software has been installed and whatever services have been told to run. Managing both deliberately, instead of by copying random files around, is what separates a system you can rebuild and trust from one nobody wants to touch.
Where you meet it: A patch window fails because a repository key expired, or a web application refuses to start after a reboot even though it works fine when started by hand.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
Imagine a well-run warehouse instead of a chaotic garage. Every item that comes in is checked, labelled, and logged so you always know what you have, where it came from, and what it depends on. A package manager is that warehouse system for software: instead of downloading random files from the internet and hoping they work, it fetches signed, tracked pieces of software and remembers exactly what was installed and what each piece needs to function.
Services are like staff on shift. Some need to already be at their desk the moment the building opens (start at boot), some are called in only when needed, and some depend on others being ready first, like a receptionist who cannot answer the phone until the phone system itself is switched on. systemd is the shift manager that starts things in the right order, restarts anyone who walks off the job unexpectedly, and keeps a written log of everyone's comings and goings.
Key ideas
If you remember nothing else from this topic, remember these.
- Package managers resolve dependencies and verify cryptographic signatures before installing anything, which is what separates them from manually downloading files.
- apt with dpkg serves Debian-family systems, while dnf with rpm serves Red Hat-family systems, and each tracks exactly what belongs to which package for clean removal.
- systemd starts services based on declared ordering and dependency directives, not a fixed numbered sequence, which is why After= and Requires= matter more than a simple list position.
- Enabling a unit links it into a target so it starts at boot, while starting a unit only affects the current session, and confusing the two is the most common deployment mistake.
- journalctl centralizes structured logs by unit and boot, replacing the need to hunt across scattered plain-text log files.
- A single expired or untrusted repository signing key can silently halt every update on a fleet, including critical security patches, with no obvious symptom until something is exploited.
Recovering a fleet after a repository signing key expires
A worked example, step by step.
Nightly patch jobs on twenty servers stop applying updates, and nobody notices until a vulnerability scan flags outdated packages weeks later.
- 01Attempt a manual updateapt update on one server returns a warning that the repository is not signed, meaning the trusted key has expired or was revoked.
- 02Confirm the key stateapt-key list (or the modern signed-by keyring file) shows the key's listed expiration date has already passed.
- 03Retrieve the current keyThe vendor publishes a renewed key; it is downloaded and imported into the trusted keyring the distribution expects.
- 04Re-run the updateapt update now completes without warnings and lists available package upgrades again.
- 05Apply the backlog of patchesapt full-upgrade installs everything that queued up during the outage window.
- 06Push the fix at scaleThe same key import and update sequence is rolled out to all twenty servers through the existing configuration management tool.
- 07Confirm service continuitysystemctl status is checked on each critical service after upgrade to ensure none failed to restart automatically.
- 08OutcomePatch automation resumes fleet-wide, and a monitoring check is added specifically for repository key validity so the failure cannot go unnoticed again.
Outcome: The fleet returns to a current patch level and a new check prevents a silent repeat of the same failure mode.
Package and service management reference
Worth keeping at hand while you work.
- apt update / apt upgrade
- Refreshes the package index, then installs available upgrades on Debian-family systems.
- dnf check-update / dnf upgrade
- Equivalent operations on Red Hat-family systems.
- dpkg -l / rpm -qa
- Lists installed packages on Debian-family and Red Hat-family systems respectively.
- systemctl start/stop/restart unit
- Controls a unit's current running state immediately.
- systemctl enable/disable unit
- Controls whether a unit starts automatically at boot.
- systemctl enable --now unit
- Enables and starts a unit in a single command.
- systemctl status unit
- Shows load state, active state, and recent log lines for a unit.
- journalctl -u unit -b
- Shows journal entries for a specific unit during the current boot.
- After= / Requires=
- Unit directives controlling start order and hard dependency respectively.
- systemd target
- A grouping of units roughly equivalent to a traditional runlevel, such as multi-user.target.
- systemd timer unit
- Schedules another unit to run, increasingly replacing cron for its logging and dependency awareness.
- apt-mark hold / dnf versionlock
- Prevents a specific package from being upgraded during a general update.
Common misunderstandings
What most beginners get wrong here.
Starting a service is enough to make sure it survives a reboot.
Starting only affects the current session; the unit must also be enabled to be linked into the boot target.
A service that runs fine when started manually will always run fine at boot.
It may depend on network or another service not yet ready, which only shows up through the unit's After= and Requires= directives at boot time.
Package managers just copy files like a manual install would.
They resolve dependency graphs, verify signatures against trusted keys, and record the transaction for later clean removal.
If updates stop working, the network connection is the most likely cause.
An expired or untrusted repository signing key is a very common and easy to overlook cause that produces a similar-looking failure.
cron and systemd timers are interchangeable with no real difference.
Timers integrate with systemd dependency ordering and journal logging, giving more visibility and control than a plain cron entry.
Exam traps
How the question writers try to catch you out.
- A scenario says a service works when run manually but not after reboot; the expected answer is that it is disabled, not that it is broken.
- Questions may distinguish enable from start explicitly, expecting the exam taker to know one is persistence and the other is immediate state.
- A dependency resolution failure during install is often confused with a missing package, when the real issue is a version conflict.
- Repository trust and signing key issues are tested as a distinct failure mode from network connectivity issues, even though symptoms look similar.
- journalctl -u versus grep on /var/log files: exam questions expect the systemd-native tool for systemd-managed services.
Check yourself
Answer in your head first, then reveal. This is not scored.
What is the difference between systemctl start and systemctl enable?
Why might a service fail at boot but succeed when started manually afterward?
What does an expired repository signing key cause?
Which command shows this boot's log entries for a single unit?
What replaces cron in many modern systemd-based systems for scheduled tasks?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
Package managers install, update, and remove software with dependency resolution: apt with dpkg on Debian-family systems, dnf with rpm on Red Hat family. Repositories define trusted sources with signing keys. systemd manages units such as services, timers, sockets, and targets, controlling start order, dependencies, and restart behaviour.
Why It Matters
Patching, deployment, and incident recovery all pass through these tools. Knowing why a service failed to start, or why a package is held back, saves hours and prevents shortcut damage such as manually copied binaries.
How It Works
- The package manager resolves dependencies, verifies signatures, and records installed state.
- systemd starts units according to declared dependencies and ordering directives.
- The journal collects structured output from units for later querying.
Where You See It
- Server builds, patch windows, application deployment, container base images, and incident recovery.
Key Terms
- Repository
- A signed source of installable packages.
- Unit file
- A systemd definition of a service, timer, or target.
- Target
- A systemd grouping roughly equivalent to a runlevel.
- Timer
- A systemd unit that schedules another unit, replacing cron for many tasks.
- journalctl
- The systemd journal query tool.
Examples
- systemctl enable --now starts a service immediately and sets it to start at boot.
- journalctl -u nginx -b shows this boot's log entries for a single unit.
Common Problems
- Broken dependencies
- Expired repository key
- Service failing on boot only
- Port already in use
- Unit masked or disabled
How It Fails
- A service that starts manually but fails at boot usually has an unmet dependency such as network or mounted storage.
- An unsigned or expired repository stops all updates including security patches.
- A masked unit silently refuses to start regardless of commands.
How to Troubleshoot
- Read systemctl status for exit code and the last log lines.
- Query the journal for the specific unit and boot.
- Check dependency ordering and required mounts or network targets.
Practical Knowledge
- Prefer restart policies and health checks over manual intervention.
- Record any manual change as configuration; undocumented state does not survive rebuilds.
Exam Coverage
- Package management commands and repositories
- systemd units, targets, and timers
- Service troubleshooting with journald
Interview Questions
- Why might a service start manually but fail during boot?
- How do you find out why a package cannot be installed?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01List all failed units on a Linux system and read one journal entry fully.
- 02Write a minimal systemd unit for a script and enable it.