Updated to Leap 16 a couple of days ago and get ‘lastb command not found’. I can’t see anything to suggest it has been removed.
On my Leap 15.6 system /usr/bin/lastb is installed with the util-linux package. You could check if that package is installed. When no, check if it is available for Leap 16.0. When yes, check if a file lastbis part of it.
1 Like
It is not part of util-linux 2.41.1-160000.2.2 in Leap 16.0 anymore.
> rpm --changelog -q util-linux|grep -B 1 lastb
* Mi Aug 02 2023 kukuk@suse.com
- Disable last and lastb for ALP, too.
--
* Mo Jul 10 2023 fvogt@suse.com
- No longer provide last and lastb on Tumbleweed. last is provided by
wtmpdb and lastb is no longer supported.
--
use --with-python[=2|3] to enable the bindings
last(1) and lastb(1):
1 Like
I am afraid that that is the answer to your question then.
I have no idea if lastb requires many other libraries, but you could try to simply copy the executable file from elsewhere and try what it does (for as long as it functions).
lastb from Leap 15.6 works but presumably will show nothing useful as it will be looking in the wrong place. I find it strange that last is actually running wtmpdb last so why not have lastb at least run wtmpdb as well.
The “lastb” command has been dropped from quite a few distros.
Simply do a web search with “linux has lastb command been replaced” or something similar. You will see numerous forum posts (Debian, Ubuntu, etc) discussing this.
To quote a reference, “… the ‘Year 2038 Problem’ with the underlying utmp and btmp files used by these commands”, and " upstream util-linux project no longer provides these commands".
One replacement is
# lslogins --failed
… among a couple other options - just seearch.
I still find it somewhat strange that having effectively replaced both last and lastb, last still exists but calls wtmpdb last but lastb doesnt call lslogins --failed. The outputs are different but why retain one of the old commands and not the other?
Is it? I do not see any reference to wtmpdb in its sources.
It is rather weak argument. Have you verified that wtmpdb actually provides the needed information?
That’s how things work out, moving into the future.
Sometimes a command is replaced by another command.
Doesn’t matter if wtmpdb doesn’t offer what folks want (as an alternative) or if it doesn’t offer the new command. Use it and move on 
Depending on your requirements, the system journal may provide the required logging information.
For Leap 16, you could add auth optional pam_audit.so to /etc/pam.d/common-auth, then sudo systemctl restart auditd.
This will show all failed TTY, GUI, and sudo login failures…
sudo ausearch -m USER_AUTH --success no
----
time->Wed Nov 19 11:16:26 2025
type=USER_AUTH msg=audit(1763504186.642:258): pid=3832 uid=1000 auid=1000 ses=4 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=/dev/pts/1 res=failed'
----
time->Wed Nov 19 11:29:47 2025
type=USER_AUTH msg=audit(1763504987.214:507): pid=5709 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="****" exe="/usr/libexec/sddm/sddm-helper" hostname=? addr=? terminal=? res=failed'
----
time->Wed Nov 19 11:31:10 2025
type=USER_AUTH msg=audit(1763505070.230:558): pid=6754 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="root" exe="/usr/bin/login" hostname=linux-lptp1 addr=? terminal=/dev/tty5 res=failed'
For example
----
time->Wed Nov 19 11:31:29 2025
type=USER_AUTH msg=audit(1763505089.046:560): pid=6820 uid=1000 auid=1000 ses=12 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="****" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed'
…and of course if the lastb output formatting was important to you, this script (with the help of ChatGPT) might suffice (saved to /usr/local/bin/ and made executable)…
#!/bin/bash
# Leap 16 replacement for lastb using auditd
# Shows failed logins in lastb-style format
sudo ausearch -m USER_AUTH --success no | awk '
/msg=/ {
# extract timestamp in seconds
if (match($0,/audit\(([0-9]+)\.[0-9]+:/,a)) {
t=strftime("%a %b %e %H:%M", a[1])
} else { t="? " }
}
/acct=/ {
# default values
u="?"
tty="?"
ip="?"
# extract account
if (match($0,/acct="([^"]+)"/,m)) u=m[1]
# extract terminal
if (match($0,/terminal=([^ ]+)/,n)) tty=n[1]
# extract host/ip
if (match($0,/hostname=([^ ]+)/,h)) ip=h[1]
# clean terminal name
if (tty ~ /^\/dev\//) tty=substr(tty,6)
if (tty=="?") {
# map exe to something user-friendly
if (match($0,/exe="([^"]+)"/,e)) {
exe=e[1]
if (exe ~ /sddm-helper/) tty="sddm"
else if (exe ~ /gdm-password/) tty="gdm"
else if (exe ~ /login/) tty="tty"
else if (exe ~ /sudo/) tty="pts"
else tty=exe
}
}
# print lastb-style line
printf "%-8s %-12s %-16s %s - %s (00:00)\n", u, tty, ip, t, t
}'
If you’ve enabled SELinux on your Leap 16.0 system then, audit is different anyway –
- Take a look at the output of:
# systemctl status setroubleshootd.service
Further information here: <https://documentation.suse.com/sle-micro/6.0/pdf/setroubleshoot_en.pdf>
and here: <https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-selinux.html#sec-selinux-troubleshoot>
Basically, it seems that, the database file ‘/var/lib/wtmpdb/wtmp.db’ is still being serviced by the Linux Kernel and, SELinux also logs access denial messages to ‘/var/log/audit/audit.log’ – the messages are then viewed with the help of “audit2why” and “audit2allow”.
Would you please stop posting junk generated by AI.
I don’t use AI in any form – my brain works in the way it does …
On this Leap 16.0 system with SELinux enabled, “lslogins --failed” is working as expected and AFAIKS the files /var/log/btmp, /var/log/wtmp and /var/lib/wtmpdb/wtmp.db are all being updated –
- as well as /var/log/audit/audit.log …
Which possibly means that, we currently have two audit mechanisms operating in parallel:
- “traditional”: /var/log/btmp and /var/log/wtmp and /var/lib/wtmpdb/wtmp.db
- “SELinux”: /var/log/audit/audit.log
PAM is the component that reports failed logins. They share the same audit subsystem for logging, which is why /var/log/audit/audit.log contains entries from both PAM (USER_AUTH) and SELinux (AVC) events.
AFAIU the systemd-logind database tracks sessions, not authentication attempts.
1 Like
The systemd journal seems to be able to provide a reasonably readable list of login failures:
# journalctl --no-hostname --identifier=unix_chkpwd
Nov 02 16:50:43 unix_chkpwd[7430]: password check failed for user (xxx)
Nov 02 16:50:45 unix_chkpwd[7503]: password check failed for user (xxx)
Nov 02 16:50:47 unix_chkpwd[7504]: password check failed for user (xxx)
-- Boot 435b5217434944b48ea8a4062f4240d8 --
Nov 03 13:04:05 unix_chkpwd[27485]: password check failed for user (yyy)
Nov 03 15:40:21 unix_chkpwd[36132]: password check failed for user (zzz)
Nov 03 15:40:23 unix_chkpwd[36204]: password check failed for user (zzz)
Nov 03 15:40:25 unix_chkpwd[36205]: password check failed for user (zzz)
Nov 03 16:38:14 unix_chkpwd[48403]: password check failed for user (xyz)
Nov 03 16:38:16 unix_chkpwd[48405]: password check failed for user (xyz)
Nov 03 17:13:38 unix_chkpwd[49407]: password check failed for user (xyz)
Nov 03 17:13:40 unix_chkpwd[49418]: password check failed for user (xyz)
-- Boot d95918a3ae1a49a8b8d9d09b350f9b40 --
Nov 04 12:27:44 unix_chkpwd[74118]: password check failed for user (xyz)
Nov 04 12:30:45 unix_chkpwd[74308]: password check failed for user (xyz)