I am using Ganymed SSH to execute commands in my Linux Machine from Java application. I have to execute 100 commands one by one.
For this in my code under for loop I am opening and closing the session for each iteration. But it is throwing some exception after 10 or 15 iterations saying that Unable to establish the connection.
I believe this is happening because the sessions are not creating frequently.
Please check the below code and guide me some good solution for achieve this.
for(String user : usersList)
{
session = connection.openSession();
session.execCommand("[ -f /home/"+user+"/.file_name] && echo \"Found\" || echo \"Not Found\"");
session.close();
}
Thanks & Regards,
Gupta Katakam
If you try to do this, you will end up in the situation that you are in. SSH has many configuration parameter but that you need to specify in the end machine. I am not sure if you have access to the end machine or not, but in case you do not have access to the target machine, please consider adding some delay on you code after doing a disconnect and re-connect. I was also facing the same problem although I was using a different library. Let me know if this things works or not, and then we can take it forward from there.
Related
The problem is exactly what the title says, I am not able to connect to mongo db server. I don't know where the problem is. Whether its with starting the server of something else. According to the code that I have written I should get the output 'Connected Successfully'. but I am not getting any output
const mongodb=require('mongodb')
const MongoClient=mongodb.MongoClient
const connectionURL='mongodb://127.0.0.1:27017'
const databaseName='task-manager'
MongoClient.connect(connectionURL,{useNewUrlParser:true},(error,client)=>{
if(error){
return console.log('Unable to connect to database')
}
console.log('Connected Successfully')
})
I have attached the related screenshots.
enter image description here
enter image description here
Please help and thank you in advance
I tried searching for things in the documentation but could not find anything. I am expecting console.log statement to work in the nodejs code that I have written.
I can see from the logs that the server is listening at 127.0.0.1:27017. However, are you sure that it is reachable?
Some other software might be blocking the access, as described in a similar question here.
You can confirm by running curl http://127.0.0.1:27017 from a console terminal, if you are on Linux or Mac, or from a PowerShell window on Windows. Some other software might be blocking the access, as described in a similar question here.
If you get a message like below, your server is fine...
user#server ~]$ curl http://127.0.0.1:27017
It looks like you are trying to access MongoDB over HTTP on the native driver port.
user#server ~]$
The second step would be to ensure that you have the right/updated driver. I see from your screenshot that your server runs MongoDB 6.0.2, which is pretty recent.
You need at least driver v4.8 as per the MongoDB/node driver compatibility list.
Then, I would suggest to try running first a piece of code that it is confirmed working well, alongside the supported driver version.
e.g. You can try theses examples, directly from the MongoDB code-samples: https://mongodb.github.io/node-mongodb-native/api-generated/mongoclient.html
I'm using .Net SDK for ACI (Azure Container Instances) to run an exec command
In the response, I only get back this object which doesn't tell me how to get the actual result of the command e.g. exit code and message.
My question is: how to retrieve the exec command results in .NET?
This is my .NET code:
string command = "ls";
var commandResponse = containerGroup.ExecuteCommand("container1", command, 100, 100);
You can get the LogContent of the container in order to find out what happened. If you are interested only in the newest item, then you can pass 1 as tailLineCount. ContainerExecResponse has a WebSocketUri property as well, which may explain why you do not directly get the info you need in the response object. WebSockets are duplex channels of communication, differing from the request-response protocol-type and in the case of WebSockets, you establish a connection which may run for a very long time, occasionally responding. So here expecting an HTTP-like behavior seems to be a misunderstanding, at least if I look at the docs.
We just started getting this error yesterday but haven't changed anything in our app. Any ideas? If we restart the function app, it will run for a short time and then start giving us this error again. The function app is in PowerShell.
Host Error: Microsoft.Azure.WebJobs.Script: Host thresholds exceeded: [Connections]
This was recently added in the runtime to track running out of available connections on the VM
https://github.com/Azure/azure-webjobs-sdk-script/pull/2063
It should point to you running out of available connections. It could be wrong or correct, but I can't tell without looking at your functions themselves.
If you would like to discuss it, then you probably should use the repo above
I'm not sure if it is the above change that caused this but it is a coding issue on my side that is now being handled correctly by Azure Functions. I created this small repo and after I commented out the close, I received the error. My real code is more complex but clearly somewhere I'm not closing it out.
$Ports = #(21,22,23,53,69,71,80,98,110,139,111,389,443,445,1080,1433,2001,2049,3001,3128,5222,6667,6868,7777,7878,8080,1521,3306,3389,5801,5900,5555,5901)
for($i = 1; $i -le $ports.Count;$i++) {
$port = $Ports[($i-1)]
$client = New-Object System.Net.Sockets.TcpClient
$beginConnect = $client.BeginConnect("123.123.123.123",$port,$null,$null)
#$client.Close();
}
I'm trying to set up a robust memcached configuration for a nodejs app with the node-memcached driver, but it does not seem to use the specified failover servers when one server dies.
My local experiment goes as follows:
shell
memcached -p 11212
node
MC = require('memcached')
c = new MC('localhost:11211', //this process does not exist
{failOverServers: ['localhost:11212']})
c.get('foo', console.log) //this will eventually time out
c.get('foo', console.log) //repeat 5 or 6 times to exceed the retries number
//wait until all the connection errors appear in the console
//at this point, the failover server should be in use
c.get('foo', console.log) //this still times out :(
Any ideas of what might we be doing wrong?
It seems that the failover feature is somewhat buggy in node-memcached.
To enable failover you must set the remove options:
c = new MC('localhost:11211', //this process does not exist
{failOverServers: ['localhost:11212'],
remove : true})
Unfortunately, this is not going to work because of the following error:
[depricated] HashRing#replaceServer is removed.
[depricated] the API has no replacement
That is, when trying to replace a dead server with a replacement from the failover list, node-memcached outputs a deprecation error from the HashRing library (which, in turn, is maintained by the same author of node-memcached). IMHO, feel free to open a bug :-)
This is come when your nodejs server not getting any session id from memcached
Please check properly in php.ini file you are setting properly or not for memcached
session.save = 'memcache'
session.path = 'tcp://localhost:11212'
My computer is connected to a domain, but when I go to create a public queue:
MessageQueue.Create(#".\testqueue");
I get this error:
A workgroup installation computer does
not support the operation.
Why might MSMQ think I'm on a workgroup computer?
I know this is late, and there is already an accepted answer, but I just had this issue and it was resolved by changing the format of the queue string.
When my queue name was this, I got the workgroup error:
".\QueueName"
When I changed it to a more formal version, there was no error and sending to the queue worked:
"FormatName:DIRECT=OS:ComputerName\private$\QueueName"
Just in case someone else comes across this post, now they have something else to try...
I got the same problem and solved it by changing it to #".\private$\QueueName"
Being part of a domain is a pre-cursor for installing MSMQ in AD-integrated mode.
It doesn't guarantee MSMQ IS installed in AD-integrated mode.
MSMQ will install in workgroup mode if:
AD integration was not selected as a setup option
AD integration was selected but failed to initialise; check event logs
Yes, the workgroup name is confusing in a domain member situation.
I was facing the same problem, take a look at solution below. I don't know the reason but creating queue in this manner works perfectly.
private MessageQueue messageQueue;
public const string DEFAULT_QUEUE_NAME = "newQueue";
public const string QUEUENAME_PREFIX = ".\\Private$\\";
public static string QueueName
{
get
{
string result = string.Format("{0}{1}", QUEUENAME_PREFIX, DEFAULT_QUEUE_NAME);
return result;
}
}
public void SendMessage()
{
string queuePath = QueueName;
MessageQueue messageQueue = MessageQueue.Create(queuePath);
messageQueue.Send("msg");
}
you can create queue for receiving message in the same manner.
Adding for documentation purpose... I was getting error "A workgroup installation computer does not support the operation" while trying to access transactional dead letter queue and it was due to not specifying the machine name. I was using period to denote computer name. e.g. "FORMATNAME:DIRECT=OS:.\SYSTEM$;DEADXACT". It does not work even with using complete format name. Problem solved after replacing the period with computer name. Below is the working code.
using (var queue = new MessageQueue($#"FORMATNAME:DIRECT=OS:{Environment.MachineName}\SYSTEM$;DEADXACT"))
{
queue.Purge();
}
It is possible that MSMQ installed in your machine as a guest user or another user so remove it from machine and install it with administrative permission.
On the server I was having trouble running MSMQ and getting different kinds of errors, including the error asked in the question.
A workgroup installation computer does not support the operation
What worked for me was not fiddling with Server Manager, but reinstalling MSMQ using Powershell.
Remove-WindowsFeature Msmq; Add-WindowsFeature MsMq
These two cmdlets can be run in a Powershell console running as Administrator. At least it fixed the error for me, but this will install the entire Msmq feature, including subfeatures.
i got this error while debugging a web site from visual studio (2015).
restarting the iisexpress solved this...