Concepts·Linux Foundation Certified System Administrator

Logging in, and what a session is

Domain 1 opens with logging in locally and remotely, which sounds like the easiest thing on the syllabus until you try to answer "who logged in yesterday" on a current Ubuntu. last is not installed, /var/run/utmp does not exist, and who prints nothing. This guide covers identity, what systemd means by a session, the difference between sudo and sudo -i, and where the login record actually lives now.

Essential Commands Guide 4 of 38 Beginner

PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
LVM2.03.31 (Ubuntu) / 2.03.36 (AlmaLinux)
nftables1.1.6 (Ubuntu) / 1.1.5 (AlmaLinux)
TimeAbout 16 min

The utmp situation is the interesting one: systemd 257 dropped utmp support, and Ubuntu 26.04 ships neither last nor wtmpdb. RHEL 10 still has the whole traditional set. Both answers are captured.

Firewallufw 0.36.2 enabled but reporting inactive / firewalld active
Network confignetplan + systemd-networkd / NetworkManager 1.56.0

Both distributions, because the commands on this page differ between them. Every output is captured on the host it belongs to.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LFCS-A01	192.168.0.70	Ubuntu 26.04 LTS	Primary host - most guides run only here	2 Core	4 GB	50 GB
LFCS-C01	192.168.0.72	AlmaLinux 10.2	The other distribution - dnf, firewalld and NetworkManager	2 Core	4 GB	50 GB

This guide includes

Use this for the opening of domain 1. This matters because the traditional login records are not there any more - who prints nothing on these hosts, and the journal is where the answer actually lives.

separating four commands that look interchangeable and are not
finding your groups, and where sudo comes from
asking what systemd means by a session
seeing why who prints nothing, and reading the login record from the journal instead
separating a login shell from a shell, and sudo from sudo -i

Before you start

guide 2 - the machines.

Who the system thinks you are
Four commands that look interchangeable and are not.
zsh Example session
```
$id; echo "---"; whoami; echo "---"; logname 2>&1; echo "---"; echo "USER=$USER  LOGNAME=$LOGNAME  HOME=$HOME"uid=1000(sysadmin) gid=1000(sysadmin) groups=1000(sysadmin),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),101(lxd)---sysadmin---sysadmin---USER=sysadmin  LOGNAME=sysadmin  HOME=/home/sysadmin$getent passwd sysadmin; echo "---"; getent passwd sysadmin | awk -F: '{printf "name=%s uid=%s gid=%s home=%s shell=%s\n", $1, $3, $4, $6, $7}'sysadmin:x:1000:1000:sysadmin:/home/sysadmin:/usr/bin/zsh---name=sysadmin uid=1000 gid=1000 home=/home/sysadmin shell=/usr/bin/zsh
```
Note
id is the authoritative answer - it reports the uid, the primary gid and every supplementary group, which is what the kernel actually checks. whoami is only the effective username.

getent passwd reads the whole name service, not just /etc/passwd - so it also answers for LDAP or SSSD accounts, where grep /etc/passwd would find nothing. That distinction is worth marks.

$USER is just an environment variable. It is set at login and nothing stops a script from changing it, so it is the least trustworthy of the four.

Note the shell field: /usr/bin/zsh, which guide 3 covers and which catches every .bashrc example on the internet.

Expected resultuid 1000, a group list, and the passwd line ending /usr/bin/zsh.

Success conditionYou can report an account's real configuration.
Groups, and where sudo comes from
The group that grants administrative access, and the two ways to list membership.
bash Example session
```
$getent group sudo; echo "---"; id -nG | tr ' ' '\n' | head -8sudo:x:27:sysadmin---sysadminadmcdromsudodipplugdevuserslxd
```
Note
getent group sudo reads the group's member list; id -nG reads it from the other end. They can disagree - a user whose *primary* group is a group will not be listed in that group's member field, which is a classic troubleshooting trap.

The group is sudo on Debian and Ubuntu and wheel on the RHEL family. Same purpose, different name, and it is the first thing to check when sudo says a user is not in the sudoers file.

Group changes need a new login to take effect, because the group list is attached to the session at login time. newgrp is the way to pick one up without logging out.

Expected resultsudo:x:27:sysadmin, then the group names one per line.

Success conditionYou can tell whether an account has admin rights.
What systemd means by a session
loginctl, which knows things who does not.
bash Example session
```
$loginctl list-sessions --no-legend | head -5; echo "sessions above"   1 1000 sysadmin - 1372  user    - no -1160 1000 sysadmin - 73476 user    - no -   2 1000 sysadmin - 1378  manager - no -sessions above$loginctl show-session $(loginctl list-sessions --no-legend | awk 'NR==1{print $1}') -p Id -p User -p Name -p Remote -p RemoteHost -p Service -p Type -p Class -p Active 2>&1 | head -12Id=1User=1000Name=sysadminRemote=yesRemoteHost=192.168.0.254Service=sshdType=ttyClass=userActive=yes
```
Note
Remote=yes and RemoteHost are the useful fields - they answer "where is this person connecting from" without reading a log.

The two sessions are a user and a manager. The manager session is the user's own systemd instance, which is what makes user-level units and timers possible - it is not a second login.

The session id changed between the two commands in this transcript, and that is not a bug: each command in these captures is its own SSH connection, so each gets a new session. On a machine you are sitting at, the id is stable.

loginctl terminate-session ID ends one, and loginctl terminate-user NAME ends all of a user's - which is how you evict somebody without rebooting.

Expected resultTwo sessions, and one of them shown as Remote=yes, RemoteHost=192.168.0.254, Service=sshd, Class=user, Active=yes.

Success conditionYou can inspect who is connected and how.
The login records that are not there any more
The traditional way to answer "who logged in recently". On this Ubuntu, none of it exists.
bash Example session
```
$for c in last lastlog lastb wtmpdb utmpdump who w; do printf '%-10s %s\n' "$c" "$(command -v $c || echo 'NOT INSTALLED')"; donelast       NOT INSTALLEDlastlog    NOT INSTALLEDlastb      NOT INSTALLEDwtmpdb     NOT INSTALLEDutmpdump   NOT INSTALLEDwho        /usr/bin/whow          /usr/bin/w$for f in /var/log/wtmp /var/log/btmp /var/run/utmp /var/lib/wtmpdb/wtmp.db; do printf '%-26s %s\n' "$f" "$(test -e $f && stat -c '%s bytes' $f || echo absent)"; done/var/log/wtmp              768 bytes/var/log/btmp              0 bytes/var/run/utmp              absent/var/lib/wtmpdb/wtmp.db    absent
```
Note
This is the single most surprising thing in Domain 1 right now. systemd 257 dropped utmp support, so nothing maintains /var/run/utmp - and Ubuntu 26.04 ships neither the old last nor its replacement wtmpdb. The wtmp file is there and stale, with no installed tool that reads it.

util-linux is installed at 2.41.3, so this is not a missing package - Ubuntu has split last and lastlog out of it deliberately.

Which means an LFCS candidate who learned last will type it on the Ubuntu image and get command not found. That is worth knowing before the clock is running.

Expected resultlast, lastlog, lastb, wtmpdb and utmpdump all NOT INSTALLED; /var/log/wtmp present at 768 bytes but /var/run/utmp absent.

Success conditionYou know why the command from the textbook fails.
who prints nothing and w prints one line
The same question, two commands, two different sources.
bash Example session
```
$who; echo "who printed $(who | wc -l) line(s)"; echo "---"; w -h; echo "w printed $(w -h | wc -l) line(s)"who printed 0 line(s)---sysadmin          192.168.0.254    09:45           0.00s   ?    sshd-session: sysadmin [priv]sysadmin pts/0    192.168.0.254    08:29   46:52   0.01s  0.01s -bashw printed 2 line(s)
```
Note
who reads utmp, which is gone, so it has nothing to report. It does not error - it succeeds and prints nothing, which is the worst kind of failure because a script checking who | wc -l silently decides nobody is logged in.

w comes from procps, not util-linux, and it walks /proc instead - so it still finds the session. The dpkg -S line in the capture is how you find out which package owns a command, and it is the fastest way to understand why two similar tools behave differently.

So on Ubuntu 26.04: w for who is here now, and the journal for who was here before.

Expected resultwho printed 0 line(s) and w printed 1 line(s).

Success conditionYou know which of the two still works.

So the journal is the login record

The same questions, answered from the journal instead.

bash Example session

$sudo journalctl --no-pager -n 6 -o short-iso _COMM=sshd-session 2>&1 | tail -72026-08-29T09:45:34+00:00 lfcs-a01 sshd-session[84436]: pam_unix(sshd:session): session opened for user sysadmin(uid=1000) by sysadmin(uid=0)2026-08-29T09:45:34+00:00 lfcs-a01 sshd-session[84483]: Received disconnect from 192.168.0.254 port 58449:11: disconnected by user2026-08-29T09:45:34+00:00 lfcs-a01 sshd-session[84483]: Disconnected from user sysadmin 192.168.0.254 port 584492026-08-29T09:45:34+00:00 lfcs-a01 sshd-session[84436]: pam_unix(sshd:session): session closed for user sysadmin2026-08-29T09:45:35+00:00 lfcs-a01 sshd-session[84494]: Accepted publickey for sysadmin from 192.168.0.254 port 58450 ssh2: ED25519 SHA256:aTxQ2TUQ/xdcGpeWfiZcVs2wa6VhoiGwnj43sn/bXyU2026-08-29T09:45:35+00:00 lfcs-a01 sshd-session[84494]: pam_unix(sshd:session): session opened for user sysadmin(uid=1000) by sysadmin(uid=0)$sudo journalctl --no-pager --since "-2h" -g "Accepted publickey" -o cat 2>&1 | tail -3; echo "---"; sudo journalctl --no-pager --since "-2h" -g "Accepted" -o cat 2>&1 | wc -lAccepted publickey for sysadmin from 192.168.0.254 port 58450 ssh2: ED25519 SHA256:aTxQ2TUQ/xdcGpeWfiZcVs2wa6VhoiGwnj43sn/bXyUAccepted publickey for sysadmin from 192.168.0.254 port 58451 ssh2: ED25519 SHA256:aTxQ2TUQ/xdcGpeWfiZcVs2wa6VhoiGwnj43sn/bXyUsysadmin :  PWD=/home/sysadmin ; USER=root ; COMMAND=/usr/bin/journalctl --no-pager --since -2h -g Accepted publickey -o cat---1359$sudo journalctl --no-pager -n 3 -o cat _SYSTEMD_UNIT=systemd-logind.service 2>&1 | tail -4Session 1357 logged out. Waiting for processes to exit.Removed session 1357.New session '1358' of user 'sysadmin' with class 'user' and type 'tty'.

Expected resultAccepted publickey for sysadmin from 192.168.0.254, session opened and closed lines, and logind reporting New session '134' and Removed session.

Success conditionYou can answer who logged in, from where, and when.

A login shell is not the same as a shell
The distinction that decides which files get read.
bash Example session
```
$bash -c 'echo "non-login: shlvl=$SHLVL  vars=$(env | wc -l)"; shopt -q login_shell && echo "login_shell: on" || echo "login_shell: off"'non-login: shlvl=1  vars=17login_shell: off$bash -lc 'echo "login:     shlvl=$SHLVL  vars=$(env | wc -l)"; shopt -q login_shell && echo "login_shell: on" || echo "login_shell: off"'login:     shlvl=1  vars=19login_shell: on$bash -c 'echo "$PATH"' ; echo "--- vs login:"; bash -lc 'echo "$PATH"'/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin--- vs login:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
```
Note
shopt -q login_shell is the definitive test, and bash -l is what makes one. A login shell reads /etc/profile and then the first of ~/.bash_profile, ~/.bash_login, ~/.profile; a non-login interactive shell reads ~/.bashrc.

The PATH is the same here, and often it is not. On a host where PATH is extended in ~/.bash_profile, a non-login shell - which is what ssh host command and cron and systemd all give you - has a shorter one. That is the root cause of half of all "works when I log in, fails from cron" reports.

Two variables of difference is small and real. Do not assume; print env | wc -l on the machine in front of you.

Expected resultlogin_shell: off with 17 variables, login_shell: on with 19 - and an identical PATH either way.

Success conditionYou can tell which startup files applied.
sudo, sudo -i, and what changes
Both make you root. They do not give you the same root.
bash Example session
```
$sudo -n whoami; echo "---"; sudo -n -i whoami; echo "---"; sudo -n sh -c 'echo "HOME=$HOME  PWD=$PWD"'; echo "---"; sudo -n -i sh -c 'echo "HOME=$HOME  PWD=$PWD"'root---root---HOME=/root  PWD=/home/sysadmin---HOME=/root  PWD=/root$sudo -n env | grep -cE '^' ; echo "vars with plain sudo"; sudo -n -i env | grep -cE '^'; echo "vars with sudo -i"12vars with plain sudo17vars with sudo -i$sudo -n sh -c 'echo "SUDO_USER=$SUDO_USER  SUDO_UID=$SUDO_UID  USER=$USER"'SUDO_USER=sysadmin  SUDO_UID=1000  USER=root
```
Note
sudo -i simulates a full login as root - it runs root's login files, starts in /root, and gets root's PATH. Plain sudo keeps your working directory and a sanitised copy of your environment.

HOME=/root in both here, which is always_set_home in the sudoers policy rather than a universal rule - on a host without it, plain sudo leaves HOME pointing at your own directory and a program writes its dotfiles into the wrong place.

SUDO_USER is the audit trail. It survives into the root environment, which is how a script can log who actually asked - and it is why sudo is preferred over su - for shared administration.

sudo -n never prompts and fails instead, which is the form to use in anything unattended.

guide 5 is next.

Expected resultroot both times, but PWD=/home/sysadmin against PWD=/root, and 12 environment variables against 16.

Success conditionYou can choose the right form deliberately.

Troubleshooting

last: command not found.

Why: Ubuntu 26.04 does not ship it, and systemd no longer maintains utmp.

Fix:Use journalctl _COMM=sshd-session or journalctl _SYSTEMD_UNIT=systemd-logind.service. On RHEL, last still works.
who prints nothing while people are logged in.

Why: It reads /var/run/utmp, which does not exist any more.

Fix:w reads /proc and still works. loginctl list-sessions is the systemd answer.
sudo says the user is not in the sudoers file.

Why: Not a member of the admin group - sudo on Debian and Ubuntu, wheel on RHEL.

Fix:usermod -aG sudo NAME, then log out and back in.
A group was added and has no effect.

Why: Group membership is attached to the session at login.

Fix:Log out and in, or newgrp GROUP for the current shell. id shows what the session actually has.
A command works after logging in and fails over ssh host command.

Why: The second is a non-login, non-interactive shell and read different startup files.

Fix:Compare bash -lc 'echo $PATH' with bash -c 'echo $PATH'. Use absolute paths in anything unattended.
A program run under sudo wrote its config into /root.

Why: HOME was set to root's home by the sudoers policy.

Fix:sudo -E preserves the environment where policy allows, or set HOME explicitly.

Official sources

← All LFCS guides

Logging in, and what a session is

This guide includes

Before you start

Who the system thinks you are

Groups, and where sudo comes from

What systemd means by a session

The login records that are not there any more

who prints nothing and w prints one line

So the journal is the login record

A login shell is not the same as a shell

sudo, sudo -i, and what changes

Troubleshooting

Official sources