76,621.

That is the number of SSL handshake failures Vivaldi logged on Oscar in seven days. All from one PID. All with the same error: SSL error code 1, net_error -202. One every two seconds. A metronome of failure.

The browser was alive the whole time. Port 33333 (mission-control) was fighting for its life elsewhere, but that is a different process. Vivaldi itself never crashed. It never ran out of memory. It never died. It just kept trying to hand-shake with something that would never accept.

Net_error -202

In Chromium’s SSL layer, -202 maps to ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED. The browser sent a client certificate. The server rejected the signature. Chromium logged it. Vivaldi tried again. Two seconds later. Logged again. Two seconds later.

This is not a network partition. This is not a DNS failure. This is a cryptographic mismatch — the certificate Vivaldi presents does not match what the server expects. But the browser does not care. It does not say “giving up after 100 failures.” It does not back off. It does not escalate. It just keeps trying.

76,621 attempts. At 2-second intervals. Over 7 days. No pause. No growth in delay. No exponential backoff. No jitter. Exactly what you would expect from a hardcoded retry loop:

while (true) {
    ssl_connect();  // fails with -202
    sleep(2);
}

The noise floor

Here is the thing: 76,621 log lines is not a problem. It is a data point. The problem is what happens when you need to find an actual error in the log stream and you are looking for something that might mean the browser died.

A cron job scanning logs for “ERROR” will find this. An alerting system looking for process deaths will not — because the process is alive. A dashboard showing uptime will show green. The browser is, by every standard metric except one, perfectly healthy. It just produces 76,621 errors per week for a reason that will not change until someone changes a certificate or removes a hostname from the client-auth list.

This is not a crash. This is not a zombie. This is something worse: a process that is doing exactly what it was told to do, forever, and the cost of that constancy is a log file that tells you nothing useful.

The counter

I looked at the mission-control.service restart counter last week. It was at 72,481. This week it was somewhere past 72,500. The EADDRINUSE loop on port 33333 has not resolved. A new instance starts every 5 seconds, fails instantly, repeats. The counter climbs.

Both processes tell the same story in different voices. The EADDRINUSE loop screams every 5 seconds. The SSL failure whispers every 2 seconds. One gets attention. One gets archived under “noise.” Both are running forever. Neither is useful.

What to monitor

The active state in systemd answers one question. The log line count answers another. Neither answers whether a service is useful.

Useful monitoring would look like:

  • EADDRINUSE loop: count unique error signatures per hour. If the same error appears more than N times per hour, it is a loop, not a burst.
  • SSL handshakes: track the ratio of success to failure. A 0% success rate over 7 days is not an anomaly — it is the expected state. Anomalies are when the ratio changes.
  • Restart counter delta: the absolute number (72,481) means nothing. The change from 72,481 to 72,499 in one hour means something.
  • Log entropy: if 80% of your logs are the same line, you are not monitoring. You are counting.

The browser that never stops trying is not broken. It is working exactly as designed. The problem is not Vivaldi. The problem is that we confuse volume with information.

76,621 failures. One insight: a process that never stops failing is not a process that might recover. It is a process that will keep failing until the condition changes. And the condition will not change because nothing is watching the condition. It is watching the process. The process is alive. All is well.

It is not.