Uncommon
Remote operations failing with SSH origin
I'm unable to push/pull/fetch in a repository where the origin uses an SSH connection.
After clicking the toolbar icon, Xit appears to attempt to fetch, displaying the progress spinner in the toolbar. However, the app fails to complete the action, eventually crashing silently after several seconds.
These same actions are working correctly when the repo is cloned in HTTPS. The repo I'm working with is hosted on GitHub, with the SSH connection/keys configured per GH's instructions.
Xit version: 1.0b14 (1) macOS version: 10.15.3
I'm afraid I don't know where to find one -- Xit quits completely silently without a crash reporter dialog, and I don't see anything in ~/Library/Logs/. Is there somewhere else I should look?
Here's what's I can find in the console, filtered on Xit's pid (52434). I press 'fetch' at 12:27:24, and Xit quits at 12:29:25:
default 12:27:20.383085-0500 launchservicesd SETFRONT: pid=52434 asn=0x-0x10f30f2 foreground=1 oldFrontPid=52402 oldFrontASN=0x-0x17699040
default 12:27:20.383768-0500 runningboardd Acquiring assertion targeting executable<Xit(501)> from originator [daemon<com.apple.coreservices.launchservicesd>:139] with description <RBSAssertionDescriptor; frontmost:52434; ID: 389-139-14179; target: 52434> attributes = {
<RBSDomainAttribute: 0x7f95e7e1aaf0; domain: com.apple.launchservicesd; name: RoleUserInteractiveFocal; sourceEnvironment: 0x0>;
}
default 12:27:20.389060-0500 runningboardd [executable<Xit(501)>:52434] Ignoring jetsam update because this process is not memory-managed
default 12:27:20.389606-0500 runningboardd [executable<Xit(501)>:52434] Set darwin role to: UserInteractiveFocal
default 12:27:20.390079-0500 runningboardd [executable<Xit(501)>:52434] Ignoring GPU update because this process is not GPU managed
default 12:27:20.399158-0500 Xit 0x112cf63a8 - WebProcessCache::setApplicationIsActive(1)
default 12:27:20.399185-0500 Xit 0x112cf69c0 - WebProcessCache::setApplicationIsActive(1)
default 12:27:20.399209-0500 Xit 0x112cf6e38 - WebProcessCache::setApplicationIsActive(1)
default 12:27:22.105621-0500 distnoted register name: com.apple.ForceSuppressedDidChangeNotification object: kCFNotificationAnyObject token: f44bc pid: 52434
default 12:27:22.218586-0500 distnoted register name: com.apple.sessionDidMoveOnConsole object: kCFNotificationAnyObject token: f44d3 pid: 52434
default 12:27:22.218678-0500 distnoted register name: com.apple.sessionDidMoveOffConsole object: kCFNotificationAnyObject token: f44d5 pid: 52434
default 12:27:24.971478-0500 mDNSResponder [R161500] DNSServiceCreateConnection START PID[52434](Xit)
default 12:27:24.971585-0500 mDNSResponder [R161501] DNSServiceQueryRecord(1D000, 0, <private>, Addr) START PID[52434](Xit)
default 12:27:24.972208-0500 mDNSResponder [R161502] DNSServiceQueryRecord(1D000, 0, <private>, AAAA) START PID[52434](Xit)
default 12:27:24.996771-0500 mDNSResponder [R161501] DNSServiceQueryRecord(1D000, 0, <private>, Addr) STOP PID[52434](Xit)
default 12:27:24.996917-0500 mDNSResponder [R161502] DNSServiceQueryRecord(1D000, 0, <private>, AAAA) STOP PID[52434](Xit)
default 12:28:50.752434-0500 sharingd Nearby start scanning with data: scan request of type 16, blob: {length = 0, bytes = 0x}, mask {length = 0, bytes = 0x}, active: 0, duplicates: 0, screen on: 300, screen off: 300, locked: 1, rssi: -60, peers: () nearby scan mode: 10, adv buf: 0, advbuf mode: 4
default 12:29:25.026387-0500 kernel AGC:: [Xit pid 52434 mux-aware] exiting, non-mux-aware app count 0, runtime: 0:03:36.559
default 12:29:25.026321-0500 hidd Connection removed: IOHIDEventSystemConnection uuid:4F29F67D-8414-4F72-816E-74A2A45A207F pid:52434 process:Xit type:Passive entitlements:0x0 caller:HIToolbox: ___GetIOHIDEventSystemClient_block_invoke + 26 attributes:(null) inactive:1 events:0 mask:0x0
default 12:29:25.026556-0500 hidd Connection removed: IOHIDEventSystemConnection uuid:E92A0326-D6ED-48CF-B67E-BA7275304728 pid:52434 process:Xit type:Passive entitlements:0x0 caller:HIServices: ___GetIOHIDEventSystemClient_block_invoke + 26 attributes:(null) inactive:1 events:0 mask:0x0
default 12:29:25.029369-0500 launchservicesd SETFRONT: pid=52402 asn=0x-0x10e10e0 foreground=1 oldFrontPid=52434 oldFrontASN=0x-0x17772786
default 12:29:25.040285-0500 mDNSResponder [R161500] DNSServiceCreateConnection STOP PID[52434](Xit)
default 12:29:25.040769-0500 runningboardd [executable<Xit(501)>:52434] Death sentinel fired!
default 12:29:25.041281-0500 launchservicesd QUITTING: pid=52434 asn=0x-0x10f30f2 foreground=1 wasFront=0
default 12:29:25.144771-0500 runningboardd Removing process: [executable<Xit(501)>:52434]
default 12:29:25.168612-0500 runningboardd Removing assertions for terminated process: [executable<Xit(501)>:52434]
And this gets printed to system.log:
Feb 21 12:29:25 Luna com.apple.xpc.launchd[1] (com.uncommonplace.Xit.11436[52434]): Service exited due to SIGPIPE | sent by Xit[52434]
What kind of server is it? Is it one that I can try connecting to?
I tried just now using ssh with a Bitbucket Server repository and it worked fine.
It's on GitHub. If it helps, this is the repo: https://github.com/a-mg/vim-wobble, and the remote is [email protected]:a-mg/vim-wobble.git.
I configured ssh using GitHub's instructions: https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh
If it's working for you, I wonder if the problem must be in my ssh keys, or in Xit reading them. I've just tried generating new ssh keys, including keys without a passphrase, but that doesn't seem to help. I'll keep looking at this.
I cloned that repository, opened it in Xit, and clicked Fetch. No crash. I tried it both with my latest build and the released 1.0b14 build.
So I guess there's something going on with your ssh setup. Would you be able to try building Xit and running it in the debugger? Otherwise I don't know how to try to replicate your situation.
As a workaround, are you able to use https instead?
That might be beyond me, I haven't used xcode and I'm not sure I can set aside more time to getting up and running. However if I get a chance I'll update.
In the meantime yes, https works fine.
Thanks for looking into it!
OK, thanks for the info. If I turn up anything else about this I'll note it here.