DEV Community

DanLin
DanLin

Posted on

How I Got Lost in Three Logs — and Still Found the User

... or why last, lastlog, and journalctl behave like three different Linux
... and why writing a simple script turned into a small investigation of Linux


🧩 Prologue — I thought it would be easy

This time, I wanted to write a script that could determine who last logged into Linux and when, and then generate a report in CSV file format.
Now... I understand why SRE engineers are gray-haired.

In theory, it's clear:

Command meaning
last login history (wtmp)
lastlog only the most recent entry
journalctl systemd login logs

But in practice — they behaved like three half-blind witnesses:

  • each knows something,
  • each lies about something,
  • and sometimes… they just remain silent.

😯 Why last isn't always telling the truth

last -w -n 1 $USER
Enter fullscreen mode Exit fullscreen mode

👎 still logged in — even if the user already logged out
👎 if wtmp is rotated → history is gone
👎 SSH/LDAP logins may not be detected
👎 PAM config affects results — different distros show different output

last doesn't guarantee that it knows the truth at all.

🤥 lastlog: seems reliable… until it isn’t

lastlog -u $USER
Enter fullscreen mode Exit fullscreen mode
Real user lastlog
Logged in 3 days ago (Never logged in)
Never logged in (Never logged in)

And how can you tell which one is real?
No way. Code fallback!


🛰 journalctl: almost a hero... if you're lucky

journalctl _UID=$(id -u $USER) --since="1 month ago"
Enter fullscreen mode Exit fullscreen mode
Issue What's happening
Various distributions systemd not available → useless command
Log rotation history disappears
Sudo required some logs are hidden
Different PAM can produce completely different events

journalctl sometimes knows everything...
...and sometimes it's as if it has never seen this user before.


🧪 Engineering solution: fallback logic

if last:
    #use that date
else if lastlog:
    #use its data
else:
    #return  “never” or “invalid”
Enter fullscreen mode Exit fullscreen mode

This is not “beautiful code.”
This is behavior in chaos.
This is already “little SRE.”


🛠 Script (user-last-login-tool)

Workflow:

  1. last → if there is a date — great
  2. if not → lastlog
  3. If still empty → return "never" or "invalid"

🔧 What I added:

  • set -euo pipefail

  • --help

  • --version

  • CSV-report

  • logging to /var/log/sre-tools

  • fallback logic for reliability

  • packaged for AUR / DEB / RPM

  • Dockerfile

  • GitHub Actions + Makefile CI

  • man-page


🧭 What surprised me the most

I expected to write a simple Bash script.
Instead, I discovered that Linux has no single “source of truth” about user logins.

That raised an interesting question:

How do SREs make decisions
when data is incomplete or contradictory?

That question turned this script
from a util — into an investigation.


👉 My project

https://github.com/DanLinX2004X/user-last-login-tool


💡 Why I’m Sharing This

LLMs can write code.
But they don’t feel the pain
when lastlog returns (Never logged in)
for a user who logged in yesterday.

That “pain” — is engineering experience.
And that can’t (yet) be generated.


🗣 Your Turn

Have you seen different behavior of these commands in:

  • Debian?
  • CentOS / RHEL?
  • LDAP / SSSD setups?

If yes — I’d really love to hear about it.
It might help make the tool actually useful.

Is this a universal Linux problem — or just my personal adventure?
Let me know 👇

Top comments (0)