One management client only: why your monitor kicks out the GUI
The management socket takes one connection at a time. A second subscriber either fails to attach or steals control from the component owning prompts.
A desktop GUI holds the management connection, so a monitoring script tries to open its own and reads nothing, or worse, the GUI stops responding to prompts. The usual conclusion is that the daemon is flaky. In the community daemon the limitation is by design: the control interface serves one connected management client at a time, and that number has nothing to do with how many users the VPN can carry.
One socket, one holder
The management channel accepts one connected client. When a second one arrives while the first is active, it waits or is refused, and there is no parallel subscriber mode hidden behind an option. Disconnecting the current holder lets the daemon accept the next one, which is a handover rather than a second channel.
That makes every extra tool a competitor. If the GUI owns the connection, a polling script either fails to attach or succeeds only after the GUI has given up, and the sequence repeats at the next reconnect. If the script attaches first, the GUI loses its control path and its prompts stop working. Neither tool reports the conflict, because each one only sees its own failed command.
| What you need | Mechanism that fits | What it cannot do |
|---|---|---|
| Periodic list of connected clients | Status file written on an interval | Deliver events as they happen |
| Interactive prompts and session control | The single management connection | Serve two controllers at once |
| Multiple consumers of either | One owner process that fans out | Exist without you writing it |
Decide which component owns control
Pick one owner for the interactive channel and let it be the only thing that connects. A GUI that manages the connection, a script that answers authentication prompts and a controller that terminates sessions all count as owners, and only one can hold the role.
When a GUI owns the connection, use the integration that GUI provides instead of fighting it. Racing the owner for the socket produces intermittent failures that look random to users, and the person debugging usually sees only the second half of the race. Note which process connects first after a reboot, because that ordering decides who wins every time. A monitor that starts before the GUI will keep the channel until the GUI gives up.
Use status snapshots for the collectors
Most monitoring needs a list, not a conversation. A periodic status file answers that without touching the control channel, and it keeps working while the GUI remains connected.
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unixThe interval is the freshness budget, so set it to what the dashboard actually needs rather than to the smallest value that seems safe. A snapshot written every few seconds is cheap; a script that reconnects to the control socket every few seconds is not, because each reconnect competes with the owner.
A snapshot is not a history and not an event feed. Connections that arrive and leave inside one interval never appear, so an audit requirement cannot be satisfied by polling a file that overwrites itself. If you need to know that a user connected at all, the snapshot is the wrong instrument.
Fan-out is a design, not a mode
If several consumers genuinely need live management data, put a single trusted component in front of the socket and let it publish narrowly chosen observations to the rest. That component owns reconnection, authentication prompts and the decision about what is safe to expose.
Build it deliberately: define which queries are allowed, log who asked, and avoid turning the fan-out layer into a remote control panel by accident. The daemon has no multi-client mode to enable, and no configuration line creates one. Treat the owner as part of the security boundary, because it holds an interface that can disconnect people. Restarting it should be a routine operation with a documented recovery path.
Treat the socket as privilege, not as metrics
The management interface can disconnect users, change state and read events that name people. Its password authenticates the client and does not encrypt the transport, so a network listener exposes the conversation to anyone who can observe it.
Prefer a local socket or a tightly restricted listener, and check which process your collector is actually addressing, since server products ship their own management APIs that behave differently. A collector pointed at the wrong daemon produces confident, wrong conclusions. Confirm the path and the owning process before you debug a query that returns nothing.