I’m a mathematician too. They’re probably speaking from an intuitive grasp of utility.

“I love life on Earth… but I love capitalism more.”

Thank-you.

And 51 feels prime. Someone sgould write a letter.

It’s “revelation,” singular. Like trivial pursuit.

You’ve linked into it, but I was just going to point at the Git book: https://git-scm.com/book/en/v2

It’s an afternoon’s reading; it does an excellent job of giving you the right mental model - and a crib aheet of commands to navigate it.

“Maybe our friend doesn’t like monads.”

Netware was rock solid.

Minimise your windows one at a time and check that the gnome keyring hasn’t popped up a dialog box sonewhere behind everything else that’s asking you if it’s okay to proceed.

It’s the gnome key ring ssh agent.

It’s possible that this has popped up a window asking gor permission / a passphrase / something and you’re not seeing that.

That’s only part of the handshake. It’d require agent input around that point.

Is this problem a recurring one after a reboot?

If it is it warrants more effort.

If not and you’re happy with rhe lack of closure, you can potentially fix this: kill the old agent (watch out to see if it respawns; if it does and that works, fine). If it doesn’t, you can (a) remove the socket file (b) launch ssh-agent with the righr flag (-a $SSH_AGENT_SOCK iirc) to listen at the same place, then future terminal sessions that inherit the env var will still look in the right place. Unsatisfactory but it’ll get you going again.

Okay, that agent process is running but it looks wedged: multiple connections to the socket seem to be opened, probably your other attempts to use ssh.

The ssh-add output looks like it’s responding a bit, however.

I’d use your package manager to work out what owns it and go looking for open bugs in the tool.

(Getting a trace of that process itself would be handy, while you’re trying again. There may be a clue in its behaviour.)

The server reaponse seems like the handshake process is close to completing. It’s not immediately clear what’s up there I’m afraid.

Please don’t ignore the advice about SSH_AGENT_SOCK. It’ll tell yoy what’s going on (but not why).

Without the ssh-agent invocation:

• what does ssh-add -L show?
• what is the original SSH_AUTH_SOCK value?
• what is listening to that? (Use lsof)

This kind of stuff often happens because there’s a ton of terrible advice online about managing ssh-agent - make sure there’s none if that baked into your shellrc.

Have you seen pictures of the sub? What makes you think the wiring was all hidden?

You joke, but watch this:

https://archive.org/details/take-me-to-titanic

from 29 minutes in. A last-minute adjustment before launch plugged in a thruster backwards; no protocol to check the behaviour prelaunch. They doscovered it when they got to the bottom.

The other thing to watch out for is if you’re splitting state between volumes, but i think you’ve already ruled that out.

I’d be cautious about the “kill -9” reasoning. It isn’t necessarily equivalent to yanking power.

Contents of application memory lost, yes. Contents of unflushed OS buffers, no. Your db will be fsyncing (or moral equivalent thereof) if it’s worth the name.

This is an aside; backing up from a volume snapshot is half a reasonable idea. (The other half is ensuring that you can restore from the backup, regularly, automatically, and the third half is ensuring that your automated validation can be relied on.)

That depends entirely on the ability to execute change. CTO is the role that should be driving this.