Debugging a systemd service without guessing
A repeatable path from failed unit to useful evidence using systemctl, journalctl, exit status, and the unit's real runtime context.
// linux · infrastructure · reliability
Joshua Rosato. Linux engineer.
I write about Linux systems, automation, observability, and the implementation details that make infrastructure easier to understand and operate.
$ systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION0 loaded units listed. $ ls -t ~/writing | head -3bsd-family-differences.mddebugging-systemd-services.mdboring-shell-scripts.md $ cat /etc/motdMake it observable.Make it repeatable.Then make it boring.
Featured writing
Notes from the systems layer.
Practical articles on Linux, operations, automation, and the failure modes that only appear once software meets a real machine.
FreeBSD, NetBSD, OpenBSD and DragonFlyBSD: what actually differs
Same 4.4BSD skeleton, four different answers to what to optimise: kernel locking, filesystems, security models, architecture coverage, and how each project runs Linux binaries.
Write boring shell scripts
A few conventions that make small Bash automation safer to rerun, easier to debug, and less surprising six months later.
About
Engineering close to the operating system.
I’m Joshua Rosato, a Linux engineer. This site is my place for technical notes, longer explanations, and useful fragments worth keeping outside a shell history.
The recurring themes are Linux internals, production reliability, automation, networking, observability, and maintainable infrastructure.
joshua@rosato:~$ fastfetch
joshua@rosato
- OS
- Arch Linux
- Role
- Linux engineer
- Focus
- Linux internals & reliability
- Shell
- bash
- Editor
- Neovim
- Uptime
- 36 days
- Posts
- 4
- Notes
- 12
- Tags
- 14