LFCS common mistakes
LFCS · Understand the traps and how to avoid them.
Editing a unit file under /etc/systemd/system/ and then immediately running `systemctl restart myapp` (or `enable --now`) without reloading the manager, so the old definition is still in force or the unit is reported as not found.
It happens because the edit appears saved and systemctl restart looks like it should pick up the change; systemd caches unit files and only re-reads them on an explicit reload, and a syntax error in the unit means the service silently refuses to start.
What to do instead
Always run systemctl daemon-reload after touching any unit file, then systemctl enable --now myapp, then verify with systemctl status myapp plus journalctl -u myapp -b --no-pager before moving on.
Writing a schedule entry into /etc/cron.d or /etc/crontab using only the five time fields plus the command, or editing a user crontab through a plain text editor and saving it elsewhere, so the job never runs.
Candidates copy the five-field syntax they remember from crontab -e into the system-wide files, forgetting that /etc/crontab and /etc/cron.d take an extra user field, and they also forget that a user crontab only takes effect when installed with crontab itself.
What to do instead
Use crontab -e for per-user jobs (five fields + command). In /etc/cron.d or /etc/crontab include the user field as the sixth field. Save to a file and load it with crontab file if editing offline, then confirm with crontab -l and check journalctl -u cron or grep CRON in the syslog for execution.
Configuring addressing with `ip addr add` / `ip route add`, confirming it works, and leaving it at that, so the address is gone after a reboot or service restart.
The ip command is the fastest way to test and gives instant feedback, so it feels like the finished answer; nothing in its output warns that the change lives only in the running kernel.
What to do instead
Translate the tested values into the distribution's persistent configuration (netplan YAML + netplan apply, nmcli con mod ... && nmcli con up, /etc/network/interfaces + ifreload -a, or systemd-networkd + systemctl restart systemd-networkd), then re-check with ip -br a and ip route after restarting the network service.
Adding a firewall rule or opening a service port with `firewall-cmd --add-service=...` and testing it successfully, without `--permanent`, or adding `--permanent` and never running `--reload`, so the rule is missing after a reload or reboot.
The non-permanent command takes effect instantly and passes the immediate test, which makes the task feel complete; the runtime/permanent split in firewalld is easy to overlook under time pressure.
What to do instead
Apply rules with firewall-cmd --permanent --add-service=<svc> (or --add-port=) and finish with firewall-cmd --reload, then verify with firewall-cmd --list-all. If a port was changed on a service itself, open the new port before restarting that service so the session is not cut off.
Hand-writing an /etc/fstab entry using a device node such as /dev/sdb1 (or a UUID typed from memory) and rebooting straight away to test it.
The device name is what lsblk shows and it works on the current boot, so it looks right; device names are not stable across reboots, and a single typo in fstab drops the system into emergency mode rather than a normal login.
What to do instead
Get the identifier from blkid and use UUID= (or LABEL=), copy the filesystem type and options from that output, then validate with mount -a and systemctl daemon-reload while still logged in. Only reboot once mount -a returns silently.
Growing a logical volume with `lvextend -L +5G /dev/vg/data` and reporting the task done because `lvs` shows the new size, while `df -h` still shows the old filesystem size.
lvextend only resizes the block device; the filesystem layer is a separate step, and the volume group / LV output confirms success loudly enough that the missing second step is easy to skip.
What to do instead
Either use lvextend -r -L +5G /dev/vg/data so the filesystem is grown in the same command, or follow up with resize2fs for ext4 or xfs_growfs <mountpoint> for XFS. Always confirm with df -h on the mount point, not just lvs.
Redirecting a command's output back into the same file it is reading, e.g. `grep -v foo /etc/hosts > /etc/hosts` or `sort file > file`, which leaves the file empty or truncated.
The intent is 'edit this file in place' and the syntax looks correct; the shell truncates the target before the command ever opens it for reading, and file permissions often allow the damage without any error message.
What to do instead
Write to a temporary file and move it into place (grep -v foo file > file.tmp && mv file.tmp file), or use a tool designed for in-place editing such as sed -i.bak. Verify the result with wc -l or by re-reading the file, never by assuming.
Running `find /etc -name *.conf` (or piping unquoted patterns into other commands) so the shell expands the glob first and find receives a different, wrong search term or several arguments.
The command is almost right and often still prints something, so the failure is invisible; the shell's pathname expansion happens before find runs, and if no match exists the literal string is passed instead of the pattern.
What to do instead
Quote every pattern passed to find or grep: find /etc -name '*.conf'. Test with a narrow path first, add -type f to cut noise, and preview destructive actions by running the command without -exec/-delete before adding them.
Adding a user to a supplementary group with `usermod -G wheel alice` (or `usermod -G sudo,devs alice`) instead of `-aG`, which silently removes the user from every group not listed in that command.
The option letter looks like 'set groups' and the command exits 0 with no warning, so the only symptom is lost access to other groups noticed much later or never during the exam.
What to do instead
Always use usermod -aG <group> <user> to append. Confirm the resulting membership with id <user> or getent group <group>. If groups must be replaced wholesale, do it deliberately and re-list every group the user should retain.
Creating an account with plain `useradd alice` and considering the task finished, ending up with no home directory on many systems and an account that cannot log in because no password was ever set.
useradd creates only a passwd and shadow entry; home directory creation depends on CREATE_HOME / /etc/login.defs and distro defaults, and the account is left locked until a password is assigned, neither of which produces a visible error.
What to do instead
Use useradd -m -s /bin/bash alice, then set the password with passwd alice, and verify with getent passwd alice, ls -ld /home/alice, and id alice. Use chage if the task involves expiry or forced password change.