Route systemd Password Prompts to the Console or Wall

You will identify which systemd password-agent units are installed, see how their path triggers work, and verify the console or wall route without handling a real passphrase. The examples use systemd 255.4-1ubuntu8.17 from Ubuntu's installed package. Allow about ten minutes. You need a shell and permission to read systemd unit state; starting or stopping these units normally requires elevated privileges.

1. Understand what the four units do

The names describe two routes and two activation mechanisms. The console service runs systemd-tty-ask-password-agent --watch --console, which continuously watches for pending requests and asks on the system console. The wall service runs the same agent with --watch --wall, forwarding requests to logged-in users through wall.

The matching .path units watch for a non-empty /run/systemd/ask-password directory. A path unit starts its associated service when a request appears. The directory is runtime state, so it is not a configuration directory to edit or populate by hand.

These agents exist for system-level secrets such as disk-encryption keys and certificate passphrases. They answer requests made by other system components. They are not a general-purpose password prompt for an interactive shell.

2. Inspect the installed unit definitions

Read the units before changing their state. This is unprivileged and avoids guessing which implementation your distribution shipped:

$ systemctl cat systemd-ask-password-console.path systemd-ask-password-console.service
$ systemctl cat systemd-ask-password-wall.path systemd-ask-password-wall.service

On this system, the console path has DirectoryNotEmpty=/run/systemd/ask-password and creates the directory if necessary. The console service is ordered around early boot and conflicts with emergency and shutdown targets. The wall service stops the console and Plymouth password agents before it starts its own watcher. That handover prevents several display agents from competing for the same request.

Checkpoint: the service definitions should show --watch --console and --watch --wall. If a local unit has different ExecStart lines, use the local definition as the authority.

3. Check pending requests without answering one

Use the agent's list mode to see whether requests are waiting:

$ systemd-tty-ask-password-agent --list
$ printf 'status=%s\n' "$?"
status=0

No output means that this command found no pending request on the installed machine at that moment. A non-zero status means the query failed, so inspect the service journal and unit state rather than inventing a passphrase.

Do not run --query casually on a production console. That option processes pending requests by asking on the calling TTY. It may cause a real disk or service password prompt. If you do need to answer a known request, confirm the request's owner and purpose first, then run it from the intended TTY.

4. Verify the path and service state

Check all four units in one read-only command:

$ systemctl show \
    -p LoadState -p FragmentPath -p ActiveState \
    systemd-ask-password-console.path \
    systemd-ask-password-console.service \
    systemd-ask-password-wall.path \
    systemd-ask-password-wall.service

A useful result has LoadState=loaded for each unit and a valid FragmentPath. The path units can be active while their services are inactive: the path is waiting for a request, and the service is only running while it is processing or watching requests. Do not treat an inactive service alone as proof that password handling is broken.

For a more readable view, use:

$ systemctl status systemd-ask-password-console.path systemd-ask-password-wall.path

Look for an active path and recent trigger information. If a request is genuinely pending, the corresponding service may be active too. The exact status text varies with timing and distribution packaging.

5. Start or stop a route only with a clear reason

Starting an agent changes system behaviour and may display or solicit a sensitive password. Stopping an agent can leave a boot, mount or service operation waiting. Treat both as privileged, service-disrupting actions. First record the current state:

$ systemctl is-active systemd-ask-password-console.path
$ systemctl is-active systemd-ask-password-wall.path

If you are diagnosing a stopped path unit and have confirmed that the host should use that route, start the path unit with sudo:

$ sudo systemctl start systemd-ask-password-console.path
$ systemctl is-active systemd-ask-password-console.path
active

Starting the path does not manufacture a password request. It enables the directory watch so a later request can activate the service. Do not start both display routes merely to make a status page look active; the wall unit's own pre-start command deliberately stops the console and Plymouth routes.

To undo that manual start, stop the same path unit after checking that no boot or storage operation is relying on it:

$ sudo systemctl stop systemd-ask-password-console.path

If the unit was enabled by the distribution or another administrator, stopping it is only a temporary state change. Do not use disable, mask a unit, or edit files under /usr/lib/systemd/system as a troubleshooting shortcut.

6. Investigate a missing or stuck prompt

First check the request directory and recent unit messages without changing anything:

$ ls -la /run/systemd/ask-password
$ journalctl -u systemd-ask-password-console.path \
    -u systemd-ask-password-console.service \
    -u systemd-ask-password-wall.path \
    -u systemd-ask-password-wall.service --since '-15 min'

If the directory is empty, there is no queued request for the agent to display. If a request exists but no path unit is active, inspect the path unit's load and condition messages. If the console route is unavailable during boot, check whether Plymouth is running: the console units include a condition that prevents them from competing with a Plymouth process.

A wall notification is not a private channel. It is sent to logged-in users, so it is unsuitable for displaying the secret itself. The agent should show the question and obtain the answer through the system password protocol; never put a passphrase in a unit argument, journal command, shell history, or a test file.