This is a question to an earlier question I had posted it turn out I need to generalize it. So I have these commands:
tracker=tcpip('127.0.0.1', 20200, 'NetworkRole', 'server');
fopen(tracker);
system('"C:\PROGRA~1\..." param1 param2')
I am using the same computer to be a listening server and a client as communication of an external device to the computer. The issue is the tracker server is waiting for the client to be started (system command).
Any feedback? Thanks
It is not possible to do it in a single script. The function fopen(tracker) will always wait for a connection. This is because it is supposed that the following instructions will be executed for a client.
Your code is saying: "Wait until a new connection is stablished (fopen). Then create a new client (system)". This doesn't make sense, so you should execute the client from a different script or program.
You can check it in the Matlab information: http://www.mathworks.es/es/help/instrument/using-tcpip-server-sockets.html
As you can see they specifically say:
MATLAB Client: This code is running on a second copy of MATLAB.
Related
I am using Ratchet Socket. I have established a new server connection and I want to stop server from running. In this scenario I have IP(Hostname) and port with me, So how can I stop that?
Is it possible to make a server connection that never ends?
When I make a server connection, first day the data output is perfect from DB, But on second day, the error is generated as "Connection is closed by foreign host". But still I can connect to that port.
Code
<?php
use Ratchet\Server\IoServer;
use MyApp\Chat;
use React\EventLoop\Factory;
use React\ZMQ\Context;
require dirname(__DIR__) . '/vendor/autoload.php';
require dirname(__DIR__) . '/src/MyApp/Chat.php';
$server = IoServer::factory(
new Chat(),
6666
);
$server->run();
?>
1.
I am using Ratchet Socket. I have established a new server connection
and I want to stop server from running. In this scenario I have
IP(Hostname) and port with me, So how can I stop that?
I assume that you currently run your Ratchet server by running it as a php script in a terminal window or screen.
eg: php push-server.php
Once you stop running the script your server will stop.
2.
Is it possible to make a server connection that never ends?
Yes, if your php script stops working from the terminal, you have to manually restart it. Its better to use a program like Supervisor (A Process Control System) which is recommended by Ratchet.
Check this link for more info http://supervisord.org/installing.html
The supervisord service will monitor your php script and will automatically restart it if it crashes which is suited for production environments.
3.
When I make a server connection, first day the data output is perfect
from DB, But on second day, the error is generated as "Connection is
closed by foreign host". But still I can connect to that port.
This is quite common and I've noticed it too. It usually happens when the server is heavily loaded or times out. Your JavaScript should check for this message and re-initiate a new connection if you see this message. You can also get it to try again after a random timer as well.
Edits
Also the __construct method for the Ratchet\Server\IoServer requires 3 prams, of which the 3rd one being optional. The first and second need to be objects of MessageComponentInterface and ServerInterface.
public function __construct(MessageComponentInterface $app, ServerInterface $socket, LoopInterface $loop = null) {
The way you instantiate the IoServer seems incorrect.
I have a command line program that listen to a tcp port until user type Q to exist. It works fine in local powershell window. But when I try to run it on another machine using powershell remote session, it just starts and quit. Is there a way to keep it running?
The remote script runs in a PowerShell that never becomes visible so AFAICT it doesn't even got a console handle by which to handle reading keyboard input.
You can take a look at the SysInternals utility - psexec. From my testing, that utility works for what you are trying to do.
Ensure you have Powershell 3 or higher since it adds support for detached sessions/background jobs.
Use a Remote Disconnected Session, described on Technet
We have Progress appservers (OE 10.0B05) running on AIX UNIX and I want write some code to check if they are up and running. The code to check the appserver would be run from a WIN2008 server. I can pull up Progress Explorer on the WIN2008 server to check the status of the appservers, but I need to write some code that can check their status programatically.
Is there any way to programatically check whether my AIX UNIX Progress appserver is up and running from a remote WIN2008 server?
To get app server status information you can use "asbman".
To get it remotely you would need some means to invoke a remote process and return a value. I'm a unix guy so I usually use "ssh" for that sort of thing.
There are Windows versions of SSH (look at the PuTTY suite for a really good free option). If you set it up to use pre-shared keys or an "agent" there are no messy login prompts to get in the way. Something like (untested):
plink -i sshkey.ppk user#server.name "asbman -name appServer -query"
"asbman" also supports -host and -port parameters if you happen to have it running on the windows box that you want to make the inquiry from.
If you have a small program that can open a socket connection, that would do it. If the program can open a socket, you can be reasonably confident the appserver is running.
You -might- be able to use the ABL SOCKET functionality to do this. Failing that, any other program which can open a socket on a remote machine and then close it will work.b
I am on an embedded platform (mipsel architecture, Linux 2.6 kernel) where I need to monitor IPC between two closed-source processes (router firmware) in order to react to a certain event (dynamic IP change because of DSL reconnect). What I found out so far via strace is that whenever the IP changes, the DSL daemon writes a special message into a UNIX domain socket bound to a specific file name. The message is consumed by another daemon.
Now here is my requirement: I want to monitor the data flow through that specific UNIX domain socket and trigger an event (call a shell script) if a certain message is detected. I tried to monitor the file name with inotify, but it does not work on socket files. I know I could run strace all the time, filtering its output and react to changes in the filtered log file, but that would be too heavy a solution because strace really slows down the system. I also know I could just poll for the IP address change via cron, but I want a watchdog, not a polling solution. And I am interested in finding out whether there is a tool which can specifically monitor UNIX domain sockets and react to specific messages flowing through in a predefined direction. I imagine something similar to inotifywait, i.e. the tool should wait for a certain event, then exit, so I can react to the event and loop back into starting the tool again, waiting for the next event of the same type.
Is there any existing Linux tool capable of doing that? Or is there some simple C code for a stand-alone binary which I could compile on my platform (uClibc, not glibc)? I am not a C expert, but capable of running a makefile. Using a binary from the shell is no problem, I know enough about shell programming.
It has been a while since I was dealing with this topic and did not actually get around to testing what an acquaintance of mine, Denys Vlasenko, maintainer of Busybox, proposed as a solution to me several months ago. Because I just checked my account here on StackOverflow and saw the question again, let me share his insights with you. Maybe it is helpful for somebody:
One relatively easy hack I can propose is to do the following:
I assume that you have a running server app which opened a Unix domain listening socket (say, /tmp/some.socket), and client programs connect to it and talk to the server.
rename /tmp/some.socket -> /tmp/some.socket1
create a new socket /tmp/some.socket
listen on it for new client connections
for every such connection, open another connection to /tmp/some.socket1 to original server process
pump data (client<->server) over resulting pairs of sockets (code to do so is very similar to what telnetd server does) until EOF from either side.
While you are pumping data, it's easy to look at it, to save it, and even to modify it if you need to.
The downside is that this sniffer program needs to be restarted every time the original server program is restarted.
This is similar to what Celada also answered. Thanks to him as well! Denys's answer was a bit more concrete, though.
I asked back:
This sounds hacky, yes, because of the restart necessity, but feasible.
Me not being a C programmer, I keep wondering though if you know a
command line tool which could do the pass-through and protocolling or
event-based triggering work for me. I have one guy from our project in
mind who could hack a little C binary for that, but I am unsure if he
likes to do it. If there is something pre-fab, I would prefer it. Can it
even be done with a (combination of) BusyBox applet(s), maybe?
Denys answered again:
You need to build busybox with CONFIG_FEATURE_UNIX_LOCAL=y.
Run the following as intercepting server:
busybox tcpsvd -vvvE local:/tmp/socket 0 ./script.sh
Where script.sh is a simple passthrough connection
to the "original server":
#!/bin/sh
busybox nc -o /tmp/hexdump.$$ local:/tmp/socket1 0
As an example, I added hex logging to file (-o FILE option).
Test it by running an emulated "original server":
busybox tcpsvd -vvvE local:/tmp/socket1 0 sh -c 'echo PID:$$'
and by connecting to "intercepting server":
echo Hello world | busybox nc local:/tmp/socket 0
You should see "PID:19094" message and have a new /tmp/hexdump.19093 file
with the dumped data. Both tcpsvd processes should print some log too
(they are run with -vvv verbosity).
If you need more complex processing, replace nc invocation in script.sh
with a custom program.
I don't think there is anything that will let you cleanly sniff UNIX socket traffic. Here are some options:
Arrange for the sender process to connect to a different socket where you are listening. Also connect to the original socket as a client. On receipt of data, notice the data you want to notice and also pass everything along to the original socket.
Monitor the system for IP address changes yourself using a netlink socket (RTM_NEWADDR, RTM_NEWLINK, etc...).
Run ip monitor as an external process and take action when it writes messages about added & removed IP addresses on its standard output.
Howdy, I am trying to run matlab remotely on windows via OpenSSH installed with Cygwin, but launching matlab in windows without the GUI seems to be impossible.
If i am logged in locally, I can launch matlab -nodesktop -nodisplay -r script, and matlab will launch up a stripped down GUI and do the command.
However, this is impossible to do remotely via ssh, as, matlab needs to display the GUI.
Does anyone have any suggestions or work arounds?
Thanks,
Bob
Short story: is your script calling exit()? Are you using "-wait"?
Long story: I think you're fundamentally out of luck if you want to interact with it, but this should work if you just want to batch jobs up. Matlab on Windows is a GUI application, not a console application, and won't interact with character-only remote connectivity. But you can still launch the process. Matlab will actually display the GUI - it will just be in a desktop session on the remote computer that you have no access to. But if you can get it to do your job without further input, this can be made to work, for some value of "work".
Your "-r script" switch is the right direction. But realize that on Windows, Matlab's "-r" behavior is to finish the script and then go back to the GUI, waiting for further input. You need to explicitly include an "exit()" call to get your job to finish, and add try/catches to make sure that exit() gets reached. Also, you should use a "-logfile" switch to capture a copy of all the command window output to a log file so you can see what it's doing (since you can't see the GUI) and have a record of prior runs.
Also, matlab.exe is asynchronous by default. Your ssh call will launch Matlab and return right away unless you add the "-wait" switch. Check the processes on the machine you're sshing to; Matlab may actually be running. Add -wait if you want it to block until finished.
One way to do this stuff just use -r to call to a standard job wrapper script that initializes your libraries and paths, runs a job, and does cleanup and exit. You'll also want to make a .bat wrapper that sets up the -logfile switch to point to a file with the job name, timestamp, and other info in it. Something like this at the M-code level.
function run_batch_job(jobname)
try
init_my_matlab_library(); % By calling classpath(), javaclasspath(), etc
feval(jobname); % assumes jobname is an M-file on the path
catch err
warning('Error occurred while running job %s: %s', jobname, err.message)
end
try
exit();
catch err
% Yes, exit() can throw errors
java.lang.System.exit(1); % Scuttle the process hard to make sure job finishes
end
% If your code makes it to here, your job will hang
I've set up batch job systems using this style in Windows Scheduler, Tidal, and TWS before. I think it should work the same way under ssh or other remote access.
A Matlab batch system on Windows like this is brittle and hard to manage. Matlab on Windows is fundamentally not built to be a headless batch execution system; assumptions about an interactive GUI are pervasive in it and hard to work around. Low-level errors or license errors will pop up modal dialog boxes and hang your job. The Matlab startup sequence seems to have race conditions. You can't set the exit status of MATLAB.exe. There's no way of getting at the Matlab GUI to debug errors the job throws. The log file may be buffered and you lose output near hangs and crashes. And so on.
Seriously consider porting to Linux. Matlab is much more suitable as a batch system there.
If you have the money or spare licenses, you could also use the Matlab Distributed Computing toolbox and server to run code on remote worker nodes. This can work for parallelization or for remote batch jobs.
There are two undocumented hacks that reportedly fix a similar problem - they are not guarantied to solve your particular problem but they are worth a try. Both of them depend on modifying the java.opts file:
-Dsun.java2d.pmoffscreen=false
Setting this option fixes a problem of extreme GUI slowness when launching Matlab on a remote Linux/Solaris computer.
-Djava.compiler=NONE
This option disables the Java just-in-time compiler (JITC). Note that it has no effect on the Matlab interpreter JITC. It has a similar effect to running Matlab with the '–nojvm' command-line option. Note that this prevents many of Matlab's GUI capabilities. Unfortunately, in some cases there is no alternative. For example, when running on a remote console or when running pre-2007 Matlab releases on Intel-based Macs. In such cases, using the undocumented '-noawt' command-line option, which enables the JVM yet prevents JAVA GUI, is a suggested compromise.
Using putty use ssh -X remote "matlab" it should work