OpenVPN says initialization completed: why no prompt returns

Nothing is stuck when the terminal goes quiet after the final log line. That is the expected shape for a foreground client: it finished starting and now sits there carrying traffic. The shell prompt is not the sign of success it looks like.

Treat the message as the boundary between startup and steady state, because that is exactly what it marks.

The message marks the end of startup, not the end of the process

OpenVPN prints that line after it has opened the device, configured the interface, installed routes and finished the TLS exchange with the peer. The process then keeps running, because its job is to hold the tunnel open and relay packets. A foreground program does not return to the prompt while it is still doing that job. Quiet output afterwards is normal, since the client only speaks when something changes.

If the line appears and the connection later dies, that is a different event, and the log will say so after the fact.

Ctrl+C is a decision, not a fix

Pressing Ctrl+C sends an interrupt, which the client handles as a request to shut down. The prompt comes back, the tunnel goes away, and any session using it ends. That looks like progress and is actually the opposite. If the goal is a persistent connection, the answer is to move the process somewhere it can keep running without your terminal, not to interrupt it.

Leaving it in the foreground is the right choice while you are debugging, because later errors stay visible in the same window. A quiet minute proves nothing either way; test a resource through the tunnel rather than watching for output.

What the message does not prove

Completion is a local statement about the client's own setup. It does not say that the far side answers, that the routes it installed match what you need, or that name resolution through the tunnel works. A split-tunnel profile can be perfectly initialized while a company share stays unreachable because the route or the DNS policy never covered it. Server-side instances print a similar line when they are ready to accept clients, which is not the same as any client being connected.

'The server started' and 'the laptop can open the share' are observations from two different places, and mixing them up sends you debugging the wrong host.

Running it without a terminal

For a persistent deployment, use the service arrangement the platform supports. On a systemd host that is an openvpn-client@office instance with the profile in /etc/openvpn/client, started and enabled so it survives reboots. Community OpenVPN also offers --daemon together with --log or --log-append, which detaches the process and sends output to a file. Either approach changes how the process runs; neither fixes a route or makes a remote application healthy.

Check that you are not starting a second instance beside one a service already manages. Two clients claiming the same profile produce confusing logs and one tunnel you did not intend.

Pick the arrangement that matches the job

Foreground for diagnosis, service for anything that must outlive the session, daemon mode when there is no service manager to lean on. Those three cover the ordinary cases, and each has a clear reason to exist. Choosing one by accident is what produces the 'it works until the window closes' report.

When the tunnel is meant to stay, confirm afterwards that it comes back after a reboot and that its logs land somewhere you will look. The initialization line appears in those logs too, at which point nobody needs to watch a terminal for it.