roll with it. however, I see another danger: At some point, admins will get lazy and not want to log in and restart the thing again and again, so they hardcode the password somewhere.

rule 1: make sure it is stable and does not need much restarting.

In most cases, you log the error, then die. And a process-monitor/helpdesk should pick up it's absence.
In some cases, the daemon needs to be up just to tell other applications it is down. (like a webserver without database backend)

Some ideas for the latter case:

Daemon detects it starts password-less, and without a TTY to ask for $pwd=<STDIN>
It does $0 = $0 . ' - NOPASSWORD' so you can see with ps -ef the state it is in.

You run a local small sendpwd perlscript that:

0. Does not show the password with ps -ef
1. sends the daemon a SIGUSR1, the daemon then creates a named pipe. for example: /tmp/fifo
2. Once the daemon gets a valid password it closes and deletes the pipe.
3. The daemon updates its process name by removing the "- NOPASSWORD" it had with $0 =~ s/ - NOPASSWORD$//;

The obvious solution was a special https web-page where you can input your password, but that was deemed undesirable by audit. figures.
nb: because nobody logged into the machine, there was no audit trace of an action. (yes, all history files were copied to a security server)