A boot hangs on a disk passphrase nobody can see, and systemd-tty-ask-password-agent is the tool that surfaces the prompt so you can answer it. This is useful for prompts such as an encrypted disk passphrase or a certificate password that must be supplied while a system operation is running. Allow about ten minutes for a simple check.
Answering a real prompt requires access to the machine and knowledge of the secret it is requesting. This guide covers the installed Ubuntu package, systemd 255.4-1ubuntu8.17, whose command reports systemd 255. The local manual page is the authority for the examples below; behaviour and available options can differ on older systemd releases.
Run the version check as your ordinary user. It does not change the system and does not need sudo:
$ systemd-tty-ask-password-agent --version
systemd 255 (255.4-1ubuntu8.17)
The package version in the example is specific to this machine. If yours differs, read the installed manual page before copying options into a script:
$ man systemd-tty-ask-password-agentCheckpoint: the command must be present and its version must be clear. Do not use a similarly named helper from another package as a substitute.
Start with --list. It reports all currently pending system password requests and does not ask for a secret:
$ systemd-tty-ask-password-agent --listWhen there are no requests, successful output is empty. On the machine used for this guide, the command returned status 0 and printed nothing. An empty result means there is nothing for this agent to display at that moment; it does not prove an operation has finished, that encryption is disabled, or that another user-facing agent is not active.
Check the exit status when using the command in a script:
$ systemd-tty-ask-password-agent --list
$ printf 'agent status: %s\n' "$?"
agent status: 0Do not parse an empty line as a password request. Requests can disappear because they expire, are cancelled, or are answered by another agent.
Use --query to process all requests pending when the command starts. It asks on the calling TTY:
$ systemd-tty-ask-password-agent --queryWarning: if a request exists, read its message carefully before entering anything. The prompt may identify a device, service or certificate, but the exact wording is supplied by the component that made the request. Enter the secret only when you recognise the request and are on a trusted terminal.
A successful exit status means the agent completed its work without reporting a failure. It is not proof the secret was correct or that the original service reached its next state. Verify the operation separately, for example with the service's own status command:
$ systemd-tty-ask-password-agent --query
$ printf 'agent status: %s\n' "$?"
agent status: 0
$ systemctl status NAME.service --no-pagerReplace NAME.service with the unit you are actually investigating. The final systemctl command may need elevated privileges to show all details, but do not add sudo to the password-agent command just because a prompt mentions a system resource.
Use --watch when requests may arrive after the command starts:
$ systemd-tty-ask-password-agent --watchThe process keeps handling password requests until it is stopped. Run it in a terminal you can monitor, and use Ctrl-C once the maintenance work is complete. Do not leave a watch process running unattended, or turn it into a permanent service without first deciding who may see and answer prompts.
This mode is easy to mistake for a hung command. A quiet terminal can simply mean no request is pending. In another terminal, list the queue:
$ systemd-tty-ask-password-agent --listStop the watcher before closing the terminal. There is no persistent configuration to undo here; terminating the process only stops this agent instance. It does not cancel the underlying operation or remove a disk-encryption requirement.
The default target for --query and --watch is the calling TTY. The manual also gives three explicit alternatives:
--console asks on /dev/console, while --console=/dev/tty1 names a particular TTY device.--wall forwards password requests to wall instead of reading a secret on the calling TTY.--plymouth asks through Plymouth, when a working Plymouth environment is available.These are routing choices, not ways to bypass the request. For example, a console agent is useful when the terminal that started a recovery task is not the terminal attached to the machine:
$ systemd-tty-ask-password-agent --console=/dev/consoleSecurity warning: take care with --wall. Wall messages are visible to logged-in users and are not a private password-entry interface. Do not use it for a secret unless the local setup and the request's intended security boundary explicitly justify that choice. Plymouth is also a display mechanism, not a guarantee that a graphical prompt is available.
--list is not proof of nothing happening. First check the exact command and the operation that should have created the request. Do not manufacture a request by editing files under /run/systemd/ask-password: those files and their reply sockets are part of the systemd password-agent protocol, and manually changing them can expose secrets or disrupt the requesting process.--query is not necessarily broken. There may be no request, the request may have expired, or another agent may have answered it first. Run --list again and inspect the initiating service. If the request appears only briefly, use --watch in a supervised terminal before repeating the operation.--list before attempting to answer anything.--query only from a trusted TTY for a recognised request.--watch is a foreground process and stopped it after maintenance.--console, --wall or --plymouth only when its visibility and target were appropriate.