rhpatrick

Nevermind, I figured it out. Unfortunately, while the Settings say it is the default, it clearly is not. Checking the "Allow multiple connections (default)" checkbox solved my problem...

I am trying to create two sessions for the same SSH entry. When I try to do this, I am not able to open the second tab with the second session. All mentions of this on Google arte too old and the menu items referenced no longer exist.

I was wrong. While 2023.1.9.0 works fine, allowing the app to upgrade itself with no active connections still results in an application that hangs at startup.

I tried a couple of recent versions and every one failed. I finally backed up to 2023.1.9.0 and had success. It appears that the newer versions were trying to open previous connections windows and was hanging. With 2023.1.9.0, it warning me that the previous attempt had failed to open these connection windows and allowed me to tell it to not try to reopen them.

I suspect that if I upgrade with no existing connections windows, it will work.

After upgrading to the latest version of RDM on my Intel-based MacBook Pro, RDM seems to start up the window never appears and no errors are reported. I have to Force Quit, which generates a huge amount of info:

Date/Time: 2023-12-27 11:05:42.649 -0600

End time: 2023-12-27 11:08:12.127 -0600

OS Version: macOS 14.1.2 (Build 23B92)

Architecture: x86_64h

Report Version: 44

Incident Identifier: 6B2AE849-AE84-4FB1-90B5-400DA3BF1D13

Data Source: Stackshots

Shared Cache: C4E0C302-D68B-3B56-9F5A-6C3FBE5367CB slid base address 0x7ff80f097000, slide 0xf097000 (System Primary)

Shared Cache: 6AAC45E6-EC03-3AD0-AC14-0EF2CF511C5B slid base address 0x7ff8287e8000, slide 0x287e8000 (DriverKit)

Command: RemoteDesktopManager

Path: /Applications/Remote Desktop Manager.app/Contents/MacOS/RemoteDesktopManager

Identifier: com.devolutions.remotedesktopmanager

Version: 2023.3.10.2 (2023.3.10.2)

Team ID: N592S9ASDB

Is First Party: No

Architecture: x86_64

Parent: launchd [1]

PID: 42256

Time Since Fork: 159s

Event: hang

Duration: 149.48s

Duration Sampled: 1.10s (process was unresponsive for 148 seconds before sampling)

Steps: 11 (100ms sampling interval)

Hardware model: MacBookPro16,1

Active cpus: 16

HW page size: 4096

VM page size: 4096

Time Since Boot: 791952s

Time Awake Since Boot: 425457s

Time Since Wake: 1204s

Fan speed: 1832 rpm

Total CPU Time: 2.277s (8.3G cycles, 7.1G instructions, 1.17c/i)

Advisory levels: Battery -> 3, User -> 2, ThermalPressure -> 0, Combined -> 2

Free disk space: 521.70 GB/931.55 GB, low space threshold 3072 MB

Vnodes Available: 80.98% (213116/263168)

Launchd throttled processes:

gui/501/com.apple.AddressBook.abd throttled after exit(): throttled samples 1-11

Preferred User Language: en-US

Country Code: US

OS Cryptex File Extents: 4

I was able to restore functionality by reverting to 2022.3.19.0.

I can verify that 2023.1.11.1 and 2023.2.5.1 have the same issue...I skipped trying earlier versions of 2023.*

OK, I was able to find the previous version and install it. Unfortunately, it is not working either. I will need to go back in time until I find the last working version...

Yeah, unfortunately, I don't know exactly which version that was... I do remember something about a database upgrade being required during the upgrade process.

Nevermind, I found that you already have a setting for this.

When I try to quit RDM on my Mac, it always displays a dialog that says "Do you really want to quit Remote Desktop Manager?". I would like to have a mechanism where I can skip this prompt (and having to push the Yes button) and just quit.

This is really problematic since without SCP/SFTP support, I have no way to transfer files to/from my VMs... Time to go dig out the command-line programs to accomplish this...

I mistakenly allowed RDM to upgrade itself on my MacBook Pro (Intel) this morning. After the upgrade, none of my existing SCP/SFTP sessions work in that double-clicking on them or trying to run Open Session does nothing.

I have isolated the problem to the fact that all of my SCP/SFTP entries use a private key without a passphrase. If I enable "Always prompt for passphrase", then the session starts, prompts me for a passphrase, and will not allow me to proceed without supplying a passphrase. As expected, if I supply a bogus passphrase, the application tries to open a connection but fails since my private keys have no passphrase.