This is probably a better question for the WRC. You've redacted some information (the domain name) that could be helpful in understanding this behavior, and I suppose you'd be comfortable sharing those specifics with them. I'd look into the details of your environment such as permissions, etc., and make sure you followed the installation documentation.
I'm confused about your mentioning Caché and IRIS for Health as those are separate products.
Depending on what your jobs are doing, they could certainly require a license. Why do you suspect a license issue, and why don't you have a license applied?
I'd check the various IRIS.logs, probably the audit and messages.log first. Without more details on what is going wrong, how it is going wrong, what you are trying to do, and information on your configuration, it's difficult to say what could be the cause.
There is no 1 universal answer to explain 100% license usage, nor 1 solution to free up the licenses. Longhua Huang asked if a restart would "fix" the license problem, but that entirely depends on what is using the licenses. If you restart and the licenses get used again, you are no better off.
You need to look at what is taking up your licenses and understand what is going on in your application that could be triggering this. Were you running the instance without license issues before? If so, what changed? Maybe it is unusually high levels of activity or some particular action, but it would be unlikely for you and your commenters to be experiencing the same issue.
You can use the methods in this linked documentation to view your license usage. If you can't make progress in investigating, the WRC can work with you to look into your license usage.
I'm not sure I understand your question, but I would strongly warn against using Task Manager to terminate Caché processes. This could cause all sorts of problems including hanging your instance. If you need to stop a process, you should use methods within Caché. If that doesn't work because the process is stuck at the OS level, then the safest thing to do is restart the instance/server. Failing that, you should reach out to the WRC.
For stopping the instance, I would agree with Kurro that "force" can be used if a clean shutdown can't continue for whatever reason, though you probably want to understand why.
That error doesn't indicate that it found the file, it just describes the path where it is looking for the file (per your configuration). If Ensemble can't access a file despite the file existing, this is likely an OS permissions issue. I would check to make sure the OS user Ensemble is using has permission to access the directories/file.
Outside of that, perhaps there would be other helpful evidence in the OS log, Ensemble ^SYSLOG, or the Ensemble event log.
"ccontrol [run | console | cterminal] instname Runs Caché in programmer mode with either no device, the console, or the terminal for $Principal (Windows only)."
Linux Mint is not supported. Dmitriy suggests you might be able to get Caché to run, but you would be on your own if issues cropped up in that environment.
Great, glad you were able to figure that out. The page I linked documents that the private key need to be in PEM format (your command seems to be taking that into account) and public key in OpenSSH format, which presumably you already had correct.
To be clear, SFTP "private key authentication" is really key pair authentication, meaning you need both a private and public key configured. If you just have 1 or the other configured, your service will attempt username authentication instead. The need for both keys is intrinsic to SFTP and is not Caché specific.
"Once you indicate you are using SFTP, you can then configure the SFTPPublicKeyFile and SFTPPrivateKeyFile settings. If you supply values for both SFTP Public Key File and SFTP Private Key File, the adapter attempts key pair authentication. It does this in conjunction with the username and password supplied via the Credentials setting, using the password in the Credentials as the passphrase for the private key."
I'd suggest reviewing the following article for suggestions on how you can debug why the key pair authentication is failing:
go to post
Hello Ravi,
This is probably a better question for the WRC. You've redacted some information (the domain name) that could be helpful in understanding this behavior, and I suppose you'd be comfortable sharing those specifics with them. I'd look into the details of your environment such as permissions, etc., and make sure you followed the installation documentation.
Running the Installer on Linux or macOS
https://docs.intersystems.com/irisforhealth20201/csp/docbook/Doc.View.cls?KEY=HXIHINST_install#HXIHINST_attended_linux_macos
Note that only Mac 10.13/10.14 are supported for that version of IRIS for Health, and for development only.
Supported Technologies
https://docs.intersystems.com/irisforhealth20201/csp/docbook/Doc.View.cls?KEY=ISP_technologies#ISP_platforms
go to post
Mohana,
I'm confused about your mentioning Caché and IRIS for Health as those are separate products.
Depending on what your jobs are doing, they could certainly require a license. Why do you suspect a license issue, and why don't you have a license applied?
I'd check the various IRIS.logs, probably the audit and messages.log first. Without more details on what is going wrong, how it is going wrong, what you are trying to do, and information on your configuration, it's difficult to say what could be the cause.
go to post
There is no 1 universal answer to explain 100% license usage, nor 1 solution to free up the licenses. Longhua Huang asked if a restart would "fix" the license problem, but that entirely depends on what is using the licenses. If you restart and the licenses get used again, you are no better off.
You need to look at what is taking up your licenses and understand what is going on in your application that could be triggering this. Were you running the instance without license issues before? If so, what changed? Maybe it is unusually high levels of activity or some particular action, but it would be unlikely for you and your commenters to be experiencing the same issue.
You can use the methods in this linked documentation to view your license usage. If you can't make progress in investigating, the WRC can work with you to look into your license usage.
go to post
I'm not sure I understand your question, but I would strongly warn against using Task Manager to terminate Caché processes. This could cause all sorts of problems including hanging your instance. If you need to stop a process, you should use methods within Caché. If that doesn't work because the process is stuck at the OS level, then the safest thing to do is restart the instance/server. Failing that, you should reach out to the WRC.
For stopping the instance, I would agree with Kurro that "force" can be used if a clean shutdown can't continue for whatever reason, though you probably want to understand why.
go to post
Hello Mathieu,
I'd at least add %Ens_EventLog but otherwise, you might find this doc page helpful.
Controlling Access to Management Portal Functions
go to post
Hi Joe,
That error doesn't indicate that it found the file, it just describes the path where it is looking for the file (per your configuration). If Ensemble can't access a file despite the file existing, this is likely an OS permissions issue. I would check to make sure the OS user Ensemble is using has permission to access the directories/file.
Outside of that, perhaps there would be other helpful evidence in the OS log, Ensemble ^SYSLOG, or the Ensemble event log.
go to post
Hello Yatin,
That's a known RDP issue that has been fixed in modern versions of Caché. To get around it you can use ccontrol console:
Using Multiple Instances of Caché
"ccontrol [run | console | cterminal] instname Runs Caché in programmer mode with either no device, the console, or the terminal for $Principal (Windows only)."
go to post
Hello Felipe,
You can find the list of supported platforms for Caché 2018.1.4 (and 2018.1.3) here:
https://docs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=ISP_technologies#ISP_platforms
Linux Mint is not supported. Dmitriy suggests you might be able to get Caché to run, but you would be on your own if issues cropped up in that environment.
go to post
Great, glad you were able to figure that out. The page I linked documents that the private key need to be in PEM format (your command seems to be taking that into account) and public key in OpenSSH format, which presumably you already had correct.
Key formats are definitely a common gotcha!
go to post
Hello Vermon,
To be clear, SFTP "private key authentication" is really key pair authentication, meaning you need both a private and public key configured. If you just have 1 or the other configured, your service will attempt username authentication instead. The need for both keys is intrinsic to SFTP and is not Caché specific.
Settings for the FTP Inbound Adapter > SSL Config
"Once you indicate you are using SFTP, you can then configure the SFTPPublicKeyFile and SFTPPrivateKeyFile settings. If you supply values for both SFTP Public Key File and SFTP Private Key File, the adapter attempts key pair authentication. It does this in conjunction with the username and password supplied via the Credentials setting, using the password in the Credentials as the passphrase for the private key."
I'd suggest reviewing the following article for suggestions on how you can debug why the key pair authentication is failing:
https://community.intersystems.com/post/using-and-debugging-netsshsession-ssh-connections
Hope that helps!