# Linux From Zero - For People Who've Never Used It and Are a Little Scared > What Linux actually is, how to find your way around its filesystem and install software, how users and permissions work, and how to start and read background services - for someone who's never touched it. --- # Linux From Zero - For People Who've Never Used It and Are a Little Scared Maybe a tutorial told you to "spin up a Linux box" and you nodded along, hoping nobody would ask a follow-up question. Maybe you SSH'd into a server at work and a black screen stared back and you closed the window. Maybe you've just heard the word "Linux" for years - wrapped in jargon, distros, penguins, people arguing online - and quietly decided it wasn't for you. It's for you. Linux is not a secret club, and it is not harder than the computer you already use every day - it's mostly the *same ideas* with the friendly wrapping paper removed. This guide starts from absolute zero: no install, nothing assumed. We build the mental model first, then walk through the four things that actually trip up newcomers - finding your way around, installing software, permissions, and services. By the end, a Linux machine will feel like a place you understand, not a place you're trespassing. > ⏭️ This guide is about Linux *itself*. If the terminal is brand new to you, or you want the filesystem > basics in depth, read [The Terminal and the Shell](/guides/the-terminal-and-shell) and > [The Filesystem, Explained](/guides/the-filesystem-explained) alongside it - we link to them rather than > re-teach them here. ## How to read this - **Brand new and want it to finally make sense?** Read in order, top to bottom. Each phase builds on the one before it and is one calm sitting. - **Already poking at a Linux box and hit a wall?** Jump to [Phase 4: Services and Logs](04-services-and-logs.md) and use the "first-day snags" cheat-card at the bottom. ## The phases 1. **[What Linux Actually Is](01-what-linux-actually-is.md)** - the kernel vs. the distribution, why there are a hundred distros that are secretly the same thing, where Linux quietly runs your life already, and what "free and open source" really buys you. 2. **[Getting Around](02-getting-around.md)** - the filesystem layout that surprises everyone (`/etc`, `/var`, `/home`, `/usr`, `/bin`), and installing software the Linux way: a package manager, not a download-and-double-click. 3. **[Users, Permissions, and `sudo`](03-users-permissions-sudo.md)** - root vs. normal users, why you *don't* run as root, what `sudo` is for, and how file permissions (`rwx`, owner/group/others) actually play out day to day. 4. **[Services and Logs](04-services-and-logs.md)** - what a background service (a daemon) is, how to start/stop/check one with `systemctl`, where to read the logs with `journalctl`, and a first-day snags cheat-card for when something refuses to behave. > This guide gets you comfortable *on* a Linux machine. Running Linux as a real server - SSH, web > services, deploying things, keeping it secure - is its own skill, covered in > [Linux for Servers](/guides/linux-for-servers) once these fundamentals feel like home. --- # What Linux Actually Is Before a single command, let's fix the one confusion that makes Linux feel bewildering from the outside: the word "Linux" gets used for two different things, and nobody tells you which one they mean. Get this straight and the whole landscape - the distros, the penguin, the arguments online - clicks into place. ## Linux is the engine, not the car **What it actually is.** Strictly speaking, *Linux* is a **kernel** - the core program that sits between your software and your hardware and manages the machine. It's the thing that decides which program gets the CPU right now, where each program's data lives in memory, and whether a program is even allowed to open a file. > ⏭️ If "kernel" is a fuzzy word, [The Manager in the Middle](/guides/what-an-operating-system-is) builds > that idea from scratch. The one-line version: the kernel is the trusted core of the operating system > that actually talks to the hardware, and everything else asks it for help. A kernel on its own is like a car engine sitting on a workshop floor - powerful, essential, and not something you can *drive*. To get a usable computer, you need everything wrapped around the engine: a way to log in, a terminal, tools to copy files and install software, maybe a desktop with windows and a mouse. That whole assembled package - kernel **plus** all the surrounding software - is a **distribution** ("distro" for short). Ubuntu, Fedora, and Debian are distributions. They are the car. Linux is the engine inside all of them. ```mermaid flowchart TD Distro["A Linux distribution (the whole car)"] --> See[desktop / login screen / terminal
what you see and touch] Distro --> Tools[installed tools: cp, ls, editor, browser
the everyday utilities] Distro --> PM[a package manager: apt, dnf
how you install more] Distro --> Kernel[The Linux kernel, the engine
the same core, everywhere] ``` πŸ“ **Terminology.** *Kernel* = the core that manages hardware. *Distribution / distro* = the kernel bundled with all the extra software that makes a complete, usable system. When someone says "I run Ubuntu," they mean a distro; the Linux kernel is humming away inside it. ## Why there are a hundred distros (and why that's less scary than it looks) Here's the part that overwhelms newcomers: search "Linux distributions" and you'll find *hundreds* - Ubuntu, Fedora, Debian, Arch, Mint, Pop!_OS, Manjaro, Alpine, on and on. It looks like a hundred different operating systems to learn. It isn't. **They are overwhelmingly the same thing underneath** - same kernel, largely the same core tools (`ls`, `cd`, `cp` work the same on all of them). A distro is mostly a set of *choices and defaults* layered on top: - **How you install software** - Debian and Ubuntu use a tool called `apt`; Fedora uses `dnf`. (We cover this in [Phase 2](02-getting-around.md).) - **What comes pre-installed** - which desktop, which default apps, which versions. - **How new vs. how stable** - Debian prizes rock-solid stability (older, battle-tested software); Fedora ships newer software sooner; Ubuntu sits in between and aims for friendliness. - **Who maintains it and why** - a company, a community, a particular philosophy. Why so many? Because Linux is *open* (more below), anyone can take an existing distro, change the defaults to suit a purpose, and release their own. Ubuntu is built on Debian; Mint is built on Ubuntu. It's less "a hundred rival operating systems" and more "a family tree of the same OS with different preferences." πŸ’‘ **Key point.** Learning "Linux" is not learning a hundred systems. Learn the shared core once - files, permissions, the package manager, services - and you can sit down at almost any distro and find your way. ⚠️ **Gotcha.** The one place distro choice genuinely matters early on is the package manager. A tutorial that says `apt install` assumes Debian/Ubuntu; on Fedora the same step is `dnf install`. When a command "doesn't exist," it's usually the other family's tool - not something you did wrong. ## Where Linux actually runs (spoiler: nearly everywhere) People think of Linux as a niche desktop for enthusiasts. The reality is almost the opposite - it's one of the most widely deployed pieces of software on Earth; you just rarely see its face: - **Servers.** The large majority of the machines that run websites and online services run Linux. When you load almost any web page, a Linux machine somewhere served it. - **Android.** Every Android phone runs on the Linux kernel. If you've used an Android device, you've been running Linux without thinking about it. - **Devices everywhere.** Wi-Fi routers, smart TVs, cars, point-of-sale terminals, the Raspberry Pi on a hobbyist's desk - a huge amount of the embedded world runs Linux. - **The cloud.** When you "rent a server" from a cloud provider, you are nearly always renting a Linux machine. **Why this saves you later.** This is why learning Linux is worth your time even if your laptop runs Windows or macOS. The moment you deploy code, rent a server, work with containers, or touch almost any backend, you're standing on Linux. It's not an exotic specialty - it's the floor you'll walk on your whole career. ## Free and open source - what that really buys you You'll hear Linux called "free and open source." That's two promises, and they're worth separating: - **Free** - you don't pay for it. You can download a full, complete distro and run it on as many machines as you like, no license fee. - **Open source** - the actual source code is public. Anyone can read it, study how it works, suggest changes, or build their own version from it. It's not a black box you have to trust blindly; it's a workshop with the doors open. πŸ“ **Terminology.** *Open source* = the source code is published under a license that lets anyone read, modify, and redistribute it. *Free* here means both "no cost" and "free as in freedom to change it" - the Linux world cares about both meanings. This is *why* there can be so many distros, *why* a router manufacturer can put Linux on its hardware without paying anyone, and *why* a global community keeps improving the same kernel. The openness is the reason the whole ecosystem exists and the reason Linux ended up everywhere. ## Recap 1. **Linux is a kernel** - the core that manages the hardware. By itself it's an engine, not a drivable car. 2. A **distribution** (Ubuntu, Fedora, Debian…) is that same kernel **plus** the surrounding software that makes a complete, usable system. 3. The hundreds of distros are **mostly the same thing** - same kernel, same core tools - differing mainly in their package manager, defaults, and how new vs. stable their software is. 4. Linux runs **nearly everywhere it matters** - most servers, every Android phone, countless devices, and the cloud - which is why learning it pays off no matter what your own laptop runs. 5. It's **free and open source**: no cost, and the code is public for anyone to read and build on - which is the reason the whole ecosystem and all those distros exist. Now that you know what you're sitting in front of, let's move around inside it - starting with a filesystem layout that catches every newcomer off guard. --- # Getting Around You know how to find your stuff on the computer you grew up with: a `C:` drive, `Program Files`, your Documents folder. Sit down at Linux and that map is gone - no `C:`, no `Program Files`, just a pile of short, cryptic folders at the top: `etc`, `var`, `usr`, `bin`. It feels like someone hid everything. Nothing's hidden. Linux just organizes the house differently, and once you know what each room is *for*, finding things becomes obvious. Then we'll cover the other day-one surprise: on Linux you don't download installers - you ask a package manager. > ⏭️ This phase gives you the working map. For the deeper "what is a path, what is a directory, how do I > navigate" mechanics, [The Filesystem, Explained](/guides/the-filesystem-explained) is the companion read. ## One tree, not many drives **What it actually is.** On Windows you have several separate trees - `C:\`, `D:\`, a USB stick as `E:\`. On Linux there is exactly **one tree**, and everything hangs off a single starting point called the **root**, written as a lone forward slash: `/`. Every file and folder lives somewhere under `/`. A second hard drive or USB stick doesn't become its own letter; it gets *attached into* the one tree at some folder (called "mounting"). πŸ“ **Terminology.** *Root* (`/`) = the very top of the filesystem, the folder that contains everything else. (Confusingly, "root" is *also* the name of the all-powerful admin user - we'll meet that root in [Phase 3](03-users-permissions-sudo.md). Same word, two meanings: the top folder, and the superuser.) ```mermaid flowchart TD root["/ (root: top of the single tree)"] --> bin["bin/ - essential commands (ls, cp, cat)"] root --> etc["etc/ - system configuration files"] root --> home["home/ - one folder per human user"] root --> usr["usr/ - most installed programs"] root --> var["var/ - data that changes: logs, databases, mail"] root --> tmp["tmp/ - scratch space, wiped on reboot"] home --> ada["ada/ - your stuff: /home/ada"] ``` ## The folders that surprise everyone, and what each is for You don't need to memorize all of them. You need a feel for the handful you'll bump into constantly: - **`/home`** - where *people's* files live. Each user gets a folder named after them: `/home/ada`. This is your equivalent of the Windows Documents-and-Desktop area - downloads, projects, per-app settings. You start here at login. The shell calls it your *home directory* and writes it with a shortcut: `~`. - **`/etc`** - **system configuration**. To change how something on the machine behaves - the SSH server, the web server, scheduled jobs - you almost always edit a text file under `/etc`. Think of it as the settings drawer for the whole system. (Memory hook: "*etc* = *Editable Text Configuration*" - not the historical origin, but a fair description.) - **`/var`** - **variable data**: stuff that grows and changes while the machine runs. The big one for beginners is logs, in `/var/log` - when something breaks and you need to find out *why*, the answer is very often a file there. Databases and mail queues live under `/var` too. - **`/usr`** - where **most installed programs** and their supporting files end up (`/usr/bin` holds the programs you can run, `/usr/lib` the shared code they need). When you install software with a package manager, this is mostly where it lands. - **`/bin`** - the **essential commands** themselves: the actual programs behind `ls`, `cp`, `cat`, and friends. (On many modern distros `/bin` is just a pointer to `/usr/bin` - same idea either way.) πŸ’‘ **Key point.** The pattern to hold onto: **`/home` is *your* stuff, `/etc` is *settings*, `/var` is *changing data and logs*, `/usr` and `/bin` are *installed programs*.** With just those four ideas you can guess where almost anything lives. **A real example.** Let's actually look at the root of the tree: ```console $ ls / bin dev home lib media opt root sbin sys usr boot etc lib64 mnt proc run srv tmp var ``` *What just happened:* `ls /` listed the contents of the root directory - the top of the whole tree. You can see the rooms just described (`etc`, `home`, `usr`, `var`, `bin`) plus several more the system uses internally. Recognizing the handful that matter is enough to feel oriented. And to see *your own* home directory: ```console $ ls ~ Desktop Documents Downloads projects ``` *What just happened:* `~` expanded to your home directory (`/home/ada`), and `ls` showed what's inside - the equivalent of "my files" on the system you already know. ## Installing software: ask, don't download Here's the habit you have to *unlearn*. On Windows or macOS, installing an app means: go to a website, download an installer, double-click it, click Next a few times. On Linux that's the unusual path. The normal way is a **package manager**. **What it actually is.** A package manager is a built-in program that installs, updates, and removes software from a trusted, curated online catalog called a **repository** (a "repo" - here it means "the catalog of installable software," not a Git repo). You tell it the name of what you want; it fetches the right version, installs everything that piece of software *also* needs, and records what it did so it can cleanly remove it later. πŸ“ **Terminology.** *Package* = one installable piece of software, bundled up with its description and its list of dependencies. *Package manager* = the tool that installs packages. *Repository* = the online catalog the package manager downloads packages from. It's closer to an app store than to hunting down installers - except it's a command, and it handles the fiddly "this needs that other thing first" chains automatically. Which command you use depends on your distro family (the one place that choice matters, per Phase 1): ```text Debian / Ubuntu β†’ apt Fedora β†’ dnf ``` The shape of the commands is the same idea on both. We'll use `apt` (Ubuntu/Debian) for the walkthrough; the `dnf` equivalents are noted alongside. ## A real `apt install`, narrated Let's install a small, friendly program called `tree` (it prints a directory as a pretty tree diagram). First, refresh the catalog so the package manager knows what's available: ```console $ sudo apt update Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease Get:2 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB] Fetched 119 kB in 1s (98.2 kB/s) Reading package lists... Done ``` *What just happened:* `apt update` didn't install anything - it downloaded the latest *list* of what's available and what versions exist. The `sudo` in front means "do this as the administrator," because changing system-wide software needs admin rights - the subject of [Phase 3](03-users-permissions-sudo.md). (On Fedora you don't usually need a separate update step; `dnf install` checks freshness itself.) Now install the program: ```console $ sudo apt install tree Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: tree 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 47.9 kB of archives. After this operation, 116 kB of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu jammy/universe amd64 tree amd64 2.0.2-1 [47.9 kB] Fetched 47.9 kB in 0s (180 kB/s) Selecting previously unselected package tree. Setting up tree (2.0.2-1) ... Processing triggers for man-db (2.10.2-0ubuntu1) ... ``` *What just happened:* `apt` found `tree` in the catalog, told you exactly what it was about to do, downloaded it, and set it up. On Fedora the same step is `sudo dnf install tree`. You were never sent to a website - the package manager did the whole errand. ⚠️ **Gotcha.** If `apt install` reports `Unable to locate package`, the usual cause is a stale catalog - run `sudo apt update` first and try again. If the *whole command* is missing (`apt: command not found`), you're probably on a distro that uses `dnf` instead - the Phase 1 lesson biting: match the tool to the distro family. Confirm it landed: ```console $ tree --version tree v2.0.2 (c) 1996 - 2022 by Steve Baker, Thomas Moore, ... ``` *What just happened:* the program answers, so it's installed and your shell can find it. The exact version doesn't matter - any answer means success. To remove a program later, you ask the same manager rather than hunting for an uninstaller: ```console $ sudo apt remove tree ``` *What just happened:* `apt` knows exactly which files it installed for `tree`, so it can cleanly take them all back out. (`sudo dnf remove tree` on Fedora.) Because *they* installed it, *they* can fully uninstall it. **Why this saves you later.** Once this clicks, software management on Linux stops feeling mysterious. Setting up a server, following a tutorial, reproducing someone's environment - it's nearly always a short list of `apt install` / `dnf install` lines. No downloading, no "is this site safe," no leftover junk. ## Recap 1. Linux has **one tree** starting at root (`/`); there are no drive letters - other disks get *mounted* into the tree. 2. The rooms that matter: **`/home`** (your files), **`/etc`** (system config), **`/var`** (changing data and `/var/log` logs), **`/usr`** and **`/bin`** (installed programs and commands). 3. `~` is a shortcut for your own home directory, where you start and keep your day-to-day work. 4. You install software with a **package manager** from a trusted catalog - **`apt`** on Debian/Ubuntu, **`dnf`** on Fedora - not by downloading installers. 5. `apt update` refreshes the catalog; `apt install ` installs (handling dependencies for you); `apt remove ` cleanly uninstalls. You can find your way and add software. But several of those commands started with `sudo`, and you may have felt a flicker of "wait, am I allowed to do that?" That's the right instinct - next, users, permissions, and what `sudo` really means. ## Try it yourself Practice moving around - `ls`, `cd projects`, `cat readme.txt`, `mkdir demo`, `tree`: ```playground-terminal ``` --- # Users, Permissions, and sudo You typed `sudo apt install` in the last phase and it worked, but maybe a small voice asked: *what is sudo, and why did installing software need it when listing files didn't?* Linux is built, from the ground up, around the idea that **not everyone is allowed to do everything** - and once you understand that, half of Linux's "why won't it let me?" moments turn into "oh, of course." This phase is the mental model behind every `permission denied` you'll ever see. ## Two kinds of user: you, and the one who can do anything **What it actually is.** Linux is **multi-user** at its core. Every account is a separate user with its own files and its own limits. But one user stands above all the rest: - **Normal users** - like `ada`. You own your files under `/home/ada`, you can run programs, but you *can't* touch the system's vital parts (you can't edit other people's files, change system config in `/etc`, or install system-wide software) without explicit permission. - **root** - the **superuser**, the administrator with no limits. root can read, change, or delete *any* file on the machine, install or remove anything, and reconfigure the whole system. root is allowed to do everything - *including* break everything. πŸ“ **Terminology.** *root* (the user) = the all-powerful administrator account, also called the *superuser*. (Don't confuse it with root the *folder*, `/`, from Phase 2 - same word, different thing.) ## Why you don't just log in as root It's tempting to think: "if root can do everything, why not just *be* root and skip the permission hassles?" Here's why every careful Linux user avoids it. When you're root, **nothing protects you from yourself**. A typo in a command can delete the entire system, because root is allowed to delete the entire system. A program you run while root has the power to do anything *you* could - so a malicious or buggy program gets the keys to everything. The permission walls that would normally stop a mistake from spreading are gone, because root is exempt from all of them. The design intention: **work as a normal user, where mistakes stay small and local, and only reach for root power for the specific moment you need it.** Your day-to-day account is a room with sensible walls. You don't tear the walls down; you step through a door when you have a reason, then step back. πŸ’‘ **Key point.** "Don't run as root" isn't superstition or gatekeeping. It's the seatbelt principle: stay in the safe seat by default, so an ordinary mistake stays ordinary instead of catastrophic. ## `sudo`: borrow root's power for exactly one command So how do you do the occasional admin task without *being* root? You use **`sudo`**. **What it actually is.** `sudo` means roughly "**s**uper**u**ser **do**": run *this one command* with root's power, just this once, then drop straight back to being your normal self. You stay logged in as you; you temporarily borrow the authority for a single command. When you put `sudo` in front of a command, Linux pauses and asks for *your* password to confirm it's really you, then runs that one command as root. The moment it finishes, you're an ordinary user again. This is why installing software needed `sudo` (it changes the whole system) but listing files didn't (reading your own folder is within a normal user's rights). Watch the difference. First, try an admin action *without* `sudo`: ```console $ apt install tree E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied) E: Unable to acquire the dpkg frontend lock. Are you root? ``` *What just happened:* as a normal user you asked to change system-wide software, and Linux refused - `Permission denied`, hinting `Are you root?`. Nothing broke; the wall did its job. Now the same thing *with* `sudo`: ```console $ sudo apt install tree [sudo] password for ada: Reading package lists... Done ... Setting up tree (2.0.2-1) ... ``` *What just happened:* `sudo` asked for *your* password (not a separate root password), confirmed you're allowed to use admin powers, and ran that single command as root. After it finished, you were instantly back to being plain `ada` - you borrowed the power for one command and gave it right back. ⚠️ **Gotcha.** `sudo` asks for *your own* password, and as you type it, **nothing appears on screen** - no dots, no stars. That's deliberate (so onlookers can't even see the length), not a frozen terminal. Type it and press Enter. After a successful `sudo`, it usually won't ask again for a few minutes. ⚠️ **The big caution.** `sudo` hands a command root's full power, so a careless `sudo` command can do real damage a non-`sudo` one couldn't. Treat every `sudo` line as "I'm about to act as the administrator - do I actually understand what this does?" The classic disaster is pasting a `sudo` command from a random website without reading it. The fix isn't fear; it's attention. ## File permissions: who can do what The other half of "Linux won't let me" is **file permissions** - the rules attached to every single file and folder saying who's allowed to do what with it. **What it actually is.** Every file carries an **owner** (usually whoever created it) and a **group** (a named set of users). The file grants three kinds of access - separately to the owner, the group, and **everyone else**: - **r** - **read**: look at the file's contents (or list a folder's entries). - **w** - **write**: change the file (or add/remove files in a folder). - **x** - **execute**: run the file as a program (or, for a folder, *enter* it). πŸ“ **Terminology.** *Owner* = the user who owns the file. *Group* = a named collection of users who can be given shared access. *Others* = everyone else on the system. Each gets its own r/w/x settings. Ask `ls` to show the details with the `-l` ("long") flag: ```console $ ls -l total 8 -rw-r--r-- 1 ada ada 220 Jun 19 09:14 notes.txt -rwxr-xr-x 1 ada ada 1320 Jun 19 09:15 backup.sh drwxr-xr-x 2 ada ada 4096 Jun 19 09:16 projects ``` *What just happened:* each line describes one item, and that cryptic block at the front is the permissions. Let's decode `notes.txt`'s `-rw-r--r--`: ```text - rw- r-- r-- β”‚ β”‚ β”‚ └── OTHERS : r-- β†’ can read only β”‚ β”‚ └─────── GROUP : r-- β†’ can read only β”‚ └──────────── OWNER : rw- β†’ can read and write └──────────────── type : '-' = a regular file ('d' = a directory) ``` So `notes.txt` can be read and edited by its owner `ada`, and only read by everyone else. Look at `backup.sh`: its `-rwxr-xr-x` adds **x** everywhere - it's a script meant to be *run*, so it carries execute permission. And `projects` begins with **d**: it's a directory, and its **x** bits mean users are allowed to enter it. ## Permission denied, decoded Now the most common day-one error makes complete sense: ```console $ cat /etc/shadow cat: /etc/shadow: Permission denied ``` *What just happened:* `/etc/shadow` (where encrypted passwords live) is readable only by root - its permissions deny read access to normal users on purpose. As `ada`, you don't have the **r** bit for "others," so Linux stops you. This isn't a bug; it's the permission system protecting something sensitive, exactly as designed. When *you should* have access (it's your own file) and still get denied, the cause is usually that the file is owned by root or another user. The fix is either `sudo` (if it's genuinely an admin task) or fixing the file's ownership/permissions - but reach for that deliberately, not reflexively. ⚠️ **Gotcha.** The reflex to "fix" a permission problem by making a file readable/writable by *everyone* (`chmod 777`, suggested everywhere online) is almost always the wrong move - it removes the protection instead of granting the right access, and on a server it's a real security hole. When you hit `permission denied`, first ask: *should* this account have access here? Usually a targeted `sudo` is the correct answer. **Why this saves you later.** Owner / group / others and r/w/x is the entire foundation. Every `permission denied`, every "the web server can't read its own config" is this one model playing out. Once you can read an `ls -l` line, these stop being mysteries and become things you can diagnose in seconds. ## Recap 1. Linux is **multi-user**: normal users (like you) have limits; **root** is the all-powerful superuser with none. 2. **Don't log in as root.** Work as a normal user so mistakes stay small; only borrow admin power for the moment you need it. 3. **`sudo`** runs *one* command as root after asking for *your* password (typed invisibly). It's how you do admin tasks safely - but every `sudo` deserves your attention. 4. Every file has an **owner**, a **group**, and **others**, each with **read / write / execute** (`rwx`) permissions - readable from an `ls -l` line. 5. **`permission denied`** almost always means the permission system is working as designed, not that something's broken. Decide whether the account *should* have access before reaching for `sudo` - and avoid the `chmod 777` "fix." You can now move around, install software, and understand who's allowed to do what. Last piece: the software that runs *without* you - background services humming on every Linux machine - and how to start them, check them, and read their logs when they misbehave. --- # Services and Logs Some programs you run and watch - `ls`, `tree`, a text editor. But the most important programs on a Linux machine are the ones you *never* see: the web server quietly answering requests, the SSH server waiting for you to log in, the clock that keeps time in sync. They start on their own, run forever in the background, and only get your attention when something's wrong. This last phase covers those invisible programs: what they are, the one command that controls them, and where to look when one misbehaves. We'll finish with a cheat-card for the snags that ambush every beginner. ## What a service (a daemon) actually is **What it actually is.** A **service** is a program designed to run **in the background, continuously**, usually without a screen or a person watching it. It starts (often when the machine boots), sits there doing its job, and keeps going until something stops it. A web server, a database, the SSH server, a scheduled-task runner - all services. The traditional Unix word for such a background program is a **daemon** (pronounced "demon," but a helpful background spirit, not an evil one). The two words are used interchangeably; many daemon names even end in `d` - `sshd` is the SSH daemon, `crond` runs scheduled jobs. πŸ“ **Terminology.** *Service / daemon* = a long-running background program with no interactive screen. It's the opposite of a command you run and watch finish; a service is *meant* to keep running. On modern Linux, services are managed by a system called **systemd**, and you talk to it through one command: **`systemctl`**. Learn the four moves below and you can manage almost any service on the box. ## `systemctl`: the four moves you actually need Everything you'll do as a beginner is one of these four verbs followed by the service's name. We'll use `ssh` (the SSH server) as the example. ### Check what a service is doing - `status` Start here. *Before* you start, stop, or worry about anything, ask how it's doing: ```console $ systemctl status ssh ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled) Active: active (running) since Thu 2026-06-19 09:02:11 UTC; 2h 14min ago Main PID: 812 (sshd) Tasks: 1 (limit: 4631) Memory: 5.6M CPU: 142ms CGroup: /system.slice/ssh.service └─812 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups" ``` *What just happened:* `systemctl status` gave you a health report. The two lines that matter most: **`Active: active (running)`** means it's up right now, and **`enabled`** (on the `Loaded:` line) means it's set to start automatically on boot. The green `●` is a quick visual "it's alive." One command answers both "is it running?" and "will it come back after a reboot?" ### Start and stop - `start` / `stop` These do exactly what they say, and they're admin actions, so they need `sudo`: ```console $ sudo systemctl stop ssh $ sudo systemctl start ssh ``` *What just happened:* `stop` told systemd to shut the service down now; `start` told it to bring it back up now. Neither prints anything when it succeeds - silence here is success. (There's also `restart`, just stop-then-start in one step, handy after you change a service's config.) ⚠️ **Gotcha.** `start` and `stop` only affect the service *right now* - they do **not** change whether it comes back after a reboot. A service you `stop` but leave `enabled` will quietly return on the next boot, which surprises people who thought they'd turned it off for good. To change boot behavior, you need the next verb. ### Make it start on boot (or not) - `enable` / `disable` ```console $ sudo systemctl enable ssh Created symlink /etc/systemd/system/multi-user.target.wants/ssh.service β†’ /lib/systemd/system/ssh.service. ``` *What just happened:* `enable` registered the service to **start automatically every time the machine boots**. It did *not* start it right now - `enable` is about the future, `start` is about this moment. (`disable` is the opposite.) For both at once: `sudo systemctl enable --now ssh`. πŸ’‘ **Key point.** Hold these two axes apart and `systemctl` stops being confusing: **`start`/`stop` = right now**, **`enable`/`disable` = on every boot**. Most "but I turned it off!" confusion is mixing up those two. ## Reading the logs - `journalctl` When a service won't start, won't behave, or you just want to know what it's been doing, you read its **logs** - the running diary programs write as they work. systemd collects these into one place called the **journal**, and you read it with **`journalctl`**. The most useful form ties the journal to a specific service: ```console $ journalctl -u ssh Jun 19 09:02:11 web-01 systemd[1]: Starting OpenBSD Secure Shell server... Jun 19 09:02:11 web-01 sshd[812]: Server listening on 0.0.0.0 port 22. Jun 19 09:02:11 web-01 sshd[812]: Server listening on :: port 22. Jun 19 09:02:11 web-01 systemd[1]: Started OpenBSD Secure Shell server. Jun 19 11:14:39 web-01 sshd[2210]: Accepted password for ada from 203.0.113.5 port 51112 ssh2 ``` *What just happened:* `-u ssh` filtered the journal down to just the `ssh` service's entries. You can read its life story: it started, began listening on port 22, and later `ada` logged in. When a service *fails* to start, this is exactly where the real reason shows up - an error line right around the failure time. Two flags worth knowing right away: ```console $ journalctl -u ssh -e # jump to the end (the newest entries) $ journalctl -u ssh -f # follow live - new lines appear as they happen (Ctrl-C to quit) ``` *What just happened:* `-e` takes you straight to the most recent entries (usually what you want first), and `-f` keeps the log streaming so you can watch a service in real time - invaluable when reproducing a problem. ⚠️ **Gotcha.** Reading other services' logs often needs `sudo` (they can contain sensitive info), so if `journalctl -u something` comes back suspiciously empty or refuses, try `sudo journalctl -u something`. And remember from Phase 2: many traditional logs *also* live as plain files under `/var/log`. **Why this saves you later.** This is the loop that fixes nearly every "the service is broken" situation: **`systemctl status`** tells you *that* it's down, **`journalctl -u `** tells you *why*. You don't guess or panic - you ask the machine what happened, and it's been keeping notes the whole time. --- ## First-day snags - the cheat-card > **You hit a wall. Match it to a row, breathe, apply the fix, and read the short *why* underneath.** | The wall you hit | The calm fix | |---|---| | `Permission denied` on a file or action | You lack the rights - if it's genuinely admin, prefix with `sudo` (Β§1) | | `command not found` for a program you expected | It isn't installed - install it with `apt`/`dnf` (Β§2) | | `Unable to locate package` from `apt install` | Stale catalog - run `sudo apt update`, then install again (Β§3) | | `sudo` seems frozen - typing shows nothing | It's waiting for your password; it's hidden on purpose - type it, press Enter (Β§4) | | A service won't start | `systemctl status `, then `journalctl -u ` to read the actual error (Β§5) | | You stopped a service but it came back after reboot | `stop` is "now"; you also need `sudo systemctl disable ` (Β§6) | ### 1. `Permission denied` You're trying to read, change, or run something your account isn't allowed to. If it's a real admin task (installing software, editing `/etc`, controlling a service), put `sudo` in front. If it's your *own* file, the owner/permissions may be off - see [Phase 3](03-users-permissions-sudo.md). Don't reflexively `chmod 777`; decide whether the account *should* have access first. ### 2. `command not found` The program isn't installed (or your shell can't find it). Install it from the package manager: `sudo apt install ` (Ubuntu/Debian) or `sudo dnf install ` (Fedora). See [Phase 2](02-getting-around.md). ### 3. `Unable to locate package` `apt` is working from an out-of-date catalog and doesn't know the package exists yet. Refresh it and retry: ```console $ sudo apt update $ sudo apt install ``` *What just happened:* `apt update` re-downloaded the list of available software; now `apt` can find what you asked for. (If `apt` itself is missing, you're likely on a `dnf`-based distro - the Phase 1 distro-family lesson.) ### 4. `sudo` looks frozen while typing your password It isn't frozen. `sudo` is asking for your password and **deliberately shows nothing** as you type - no dots, no stars - so onlookers can't see its length. Type it normally and press Enter. See [Phase 3](03-users-permissions-sudo.md). ### 5. A service won't start Don't guess - ask the machine in two steps: ```console $ systemctl status $ journalctl -u -e ``` *What just happened:* `status` confirms it's down and often shows the last error line; `journalctl -u -e` shows the end of that service's log, where the real reason (a bad config line, a port already in use, a missing file) is almost always spelled out. ### 6. A stopped service came back after reboot `stop` only affects the service right now; it doesn't change boot behavior. To keep it from auto-starting, disable it too: ```console $ sudo systemctl disable ``` *What just happened:* `disable` unregistered the service from the boot sequence, so it stays down across reboots (`stop` + `disable` = down now *and* later). --- ## You're no longer a stranger here Look at what you can now do. You know **what Linux actually is** - a kernel, wrapped into a distribution, running most of the world's servers. You can **find your way around** the one-tree filesystem and **install software** from a package manager. You understand **users, permissions, and `sudo`**, so `permission denied` is information, not a wall. And you can **start, check, and read the logs of services**, so a misbehaving daemon is a thing you diagnose, not fear. That's the cold start - genuinely the hardest part - behind you. **Where to go next.** You're comfortable *on* a Linux machine. The natural next step is running one as a real server: logging in remotely over SSH, running web services, keeping it updated and secure, and deploying actual software. That's the next guide: **[Linux for Servers](/guides/linux-for-servers)**. You now have exactly the foundation it builds on.