Route systemd Password Prompts to the Console or Wall

A disk needing a passphrase at boot, or a certificate wanting one, gets its prompt from systemd-ask-password-console.service. This guide shows you how to read the four units behind that prompt, check for a pending request without answering it, and confirm the console or wall route is working, all without touching a real passphrase. Examples use systemd 255.4-1ubuntu8.17 from Ubuntu's installed package. Allow about ten minutes.

The route

Jump straight to the step you need, or tick off Done means at the end.

1. Know what the four units do
2. Inspect the installed unit definitions
3. Check pending requests without answering one
4. Verify the path and service state
5. Start or stop a route only with a clear reason
6. Investigate a missing or stuck prompt

You need: a shell and permission to read systemd unit state.
You will not need: a real password prompt to answer; everything here is read-only until the optional start/stop step, which needs sudo.

1. Know what the four units do

Two routes, two activation mechanisms, four units. The console service runs systemd-tty-ask-password-agent --watch --console, watching continuously for pending requests and asking on the system console. The wall service runs the same agent with --watch --wall, forwarding requests to logged-in users through wall.

The path units are the trigger. Each watches for a non-empty /run/systemd/ask-password directory and starts its matching service when a request appears.
The directory is runtime state. It is not somewhere you edit or populate by hand.
These agents are for system secrets. Disk-encryption keys, certificate passphrases, that sort of thing. They are not a general-purpose prompt for an interactive shell.

2. Inspect the installed unit definitions

Read the units before changing their state. This is unprivileged and stops you 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 it does not exist. 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 starting its own watcher, so agents do not compete for the same request.

Checkpoint

The service definitions should show --watch --console and --watch --wall. If a local unit has different ExecStart lines, treat the local definition as the authority, not this guide.

3. Check pending requests without answering one

Use the agent's list mode to see whether anything is waiting:

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

No output means no pending request on the installed machine at that moment.
A non-zero status means the query failed. Inspect the service journal and unit state rather than inventing a passphrase to make it pass.

Warning

Do not run --query casually on a production console. It processes pending requests by asking on the calling TTY, which may trigger a real disk or service password prompt. If you do need to answer a known request, confirm its 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 healthy result shows LoadState=loaded for each unit and a valid FragmentPath. The path units can sit active while their services are inactive: the path waits for a request, and the service only runs while it is processing or watching one. An inactive service on its own is not proof that password handling is broken.

For a more readable view:

$ 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 matching service may be active too. 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 one 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 the host should use that route, start it 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 just 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, so running both is fighting the design.

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

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

Warning

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

6. Investigate a missing or stuck prompt

Check the request directory and recent unit messages first, 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'

Empty directory: no queued request for the agent to display.
A request exists but no path unit is active: inspect the path unit's load and condition messages.
Console route unavailable at boot: check whether Plymouth is running. The console units include a condition that stops them competing with a Plymouth process.

Warning

A wall notification is not a private channel; it goes to every logged-in user, so it is unsuitable for showing 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.

Done means

You can tell the console and wall services apart from their directory-watching path units.
You used systemd-tty-ask-password-agent --list to inspect pending requests without answering one.
The local unit files confirmed the expected --watch mode and route.
You checked path state before changing it and used sudo only for an intentional service-state change.
No password ended up in a command, log, unit file or shared wall message.