How to Use the Linux logname Command to Identify the Original Login User

When you are managing a Linux server, it is common practice to log in using a standard user account and then elevate your privileges using the su or sudo -i commands to become the root user. Once you switch users, the environment variables change, and the whoami command will simply report that you are “root”. If you are auditing a system, investigating a script, or writing an automation process that needs to know the original user who initiated the SSH session before any privilege escalation occurred, you cannot rely on whoami. Instead, you must use the Linux logname command.

How the logname Command Works

The logname utility is a standard POSIX tool that ships by default on virtually all Linux and Unix-like operating systems. Its sole function is to print the name of the user who originally logged into the current terminal session. It does this by reading the system’s utmp file (typically located at /var/run/utmp), which acts as a database tracking all currently active login sessions on the server.

Executing the Command

Using the command is incredibly straightforward, as it requires no arguments or complex syntax.

1. Open your terminal or SSH into your server.
2. Type the command: logname
3. Press Enter.

The system will instantly output the username of the account that established the initial connection.

Comparing logname to whoami

To understand the unique value of logname, you must compare it directly to whoami during a privilege escalation scenario.

1. Log into your server as a standard user (for example, “jsmith”).
2. Run whoami. The output will be jsmith.
3. Run logname. The output will also be jsmith.
4. Now, switch to the root user by running: sudo su -
5. Run whoami again. The output is now root.
6. Run logname again. The output remains jsmith.

Even though your current effective user ID is zero (root), logname cuts through the escalation layers and correctly identifies the human operator who authenticated the initial session.

Practical Use Cases in Bash Scripting

System administrators frequently use logname within shell scripts that must be executed with root privileges, but which need to perform actions relative to the user who executed them. For example, if you write a script that must install system-wide software (requiring root) but then needs to write a configuration file to the home directory of the user who ran the script, logname provides the correct path.

Consider this script snippet:

#!/bin/bash
# This script must run as root
if [ "$EUID" -ne 0 ]; then
  echo "Please run with sudo"
  exit
fi

ORIGINAL_USER=$(logname)
echo "Installing software globally..."
# Output configuration to the user's specific home folder
echo "config=true" > /home/$ORIGINAL_USER/.myapp_config
chown $ORIGINAL_USER:$ORIGINAL_USER /home/$ORIGINAL_USER/.myapp_config

If you used whoami in this script, it would attempt to write the file to /root/.myapp_config, entirely defeating the purpose of the script.

Handling Errors When Using logname

Because logname relies on the utmp file, it will only work if the process is attached to a controlling terminal (a TTY). If you attempt to run logname within a background cron job, a systemd service, or a detached screen session where a standard login did not occur, the command will fail and output the error message: logname: no login name. In fully automated environments without a human terminal session, you must rely on other environmental variables like $USER or execute specific commands as defined service users.