Weird delay when using "tail -f" command - unix

To monitor a log file I have to connect to an ssh connection and redirect the output of the log file(let's call it RemoteLog.txt) out to a local machine so it can be read by a java program and put on a GUI.
Right now I have the output redirected out of the ssh connection and onto the local machine with the command:
ssh remote#ip.address tail logs/RemoteLog.txt -f > ~/Log/LocalLog.txt
and everything works fine technically with one exception: for some reason LocalLog.txt only gets updated with the changes to RemoteLog.txt every 35 seconds to the millisecond.
It doesn't matter the number of changes to RemoteLog, the number of lines specified with the tail command, or using the >> operator vs the > operator; there is always a 35 second delay between updates of LocalLog.txt while RemoteLog is constantly updating.
Does anyone have any clue why this might be?

Related

About expected timeouts in RobotFramework SSHLibrary

I’m a newb with respect to Robot Framework.
I’m writing a test procedure that is expected to
connect to another machine
perform an image update (which causes the unit to close all services and reboot itself)
re-connect to the unit
run a command that returns a known string.
This is all supposed to happen within the __init__.robot module
What I have noticed is that I must invoke the upgrade procedure in a synchronous, or blocking way, like so
Execute Command sysupgrade upgrade.img
This succeeds in upgrading the unit, but the robotframework script hangs executing the command. I suspect this works because it keeps the ssh session alive long enough for the upgrade to reach a critical junction where the session is closed by the remote host, the host expects this, the upgrade continues, and this does not cause the upgrade to fail.
But the remote host appears to close the ssh session in such a way that the robotframework script does not detect it, and the script hangs indefinitely.
Trying to work around this, I tried invoking the remote command like so
Execute Command sysupgrade upgrade.img &
But then the update fails because the connection appear to drop and leaves the upgrade procedure incomplete.
If instead I execute it like this
Execute Command sysupgrade upgrade.img &
Sleep 600
Then this also fails, for some reason I am unable to deduce.
However, if I invoke it like this
Execute Command sysupgrade upgrade.img timeout=600
The the command succeeds in updating the unit, and after the set timeout period, the robotframework script does indeed resume, but since it has arrived at the timeout, the test has (from the point of view of robotframework) failed.
But this is actually an expected failure, and should be ignored. The rest of the script would then reconnect to the host and continue the remaining test(s)
Is there a way to treat the timeout condition as non-fatal?
Here is the code, as explained above, the __init__.robot initialization module is expected to perform the upgrade and then reconnect, leaving the other xyz.robot files to be run and continue testing the applications.
The __init__.robot file:
*** Settings ***
| Library | OperatingSystem |
| Library | SSHLibrary |
Suite Setup ValidationInit
Suite Teardown ValidationTeardown
*** Keywords ***
ValidationInit
Enable SSH Logging validation.log
Open Connection ${host}
Login ${username} ${password}
# Upload the firmware to the unit.
Put File ${firmware} upgrade.img scp=ALL
# Perform firmware upgrade on the unit.
log "Launch upgrade on unit"
Execute Command sysupgrade upgrade.img timeout=600
log "Restart comms"
Close All Connections
Open Connection ${host}
Login ${username} ${password}
ValidationTeardown
Close All Connections
log “End tests”
This should work :
Comment Change ssh client timeout configuration set client configuration timeout=600 Comment "Launch upgrade on unit" SSHLibrary.Write sysupgrade upgrade.img SSHLibrary.Read Until expectedResult Close All Connections
You can use 'Run Keyword And Ignore Error' to ignore the failgure. Or here I think you should use write command if you do not care the execution result.

Error: Port 5000 is not open, could not start functions emulator

✔ Deploy complete!
Project Console: https://console.firebase.google.com/project/socialape-6b2f7/overview
Ayhan-MacBookPro:socialape-functions macbook$ firebase serve
=== Serving from '/Users/macbook/Desktop/socialape-functions'...
Error: Port 5000 is not open, could not start functions emulator.
Run lsof -t -i tcp:5000 | xargs kill from your Terminal.
A common cause for this error occurs when the Firebase emulator is not cleanly shut down (e.g., closing your IDE that's running the emulator in an embedded Terminal session) This will leave the process running in the background and occupies the emulator's default port.
To resolve the conflict, find the process ID running on the port (here 5000) from your Terminal command line and then kill it.
The above one-liner finds the process ID and pipes it directly to kill (h/t #manav).
For additional info, check out: Find (and kill) process locking port 3000 on Mac
The bug seems to be on not your end
It is caused by a bug in a dependency (node portfinder).
A quick fix to edit it might be to use the old version of node portfinder (v 1.0.21). Alternatively, you can do it by editing node_modules/firebase-tools/lib/emulator/controller.js and changing yield pf.getPortPromise({ port, stopPort: port }) to yield pf.getPortPromise({ port, stopPort: port + 1 }).
You can see the answer to your question completely here in this SO link.
If you are facing this issue in macOS Pro then this solution is for you.
In MacOS , Port 5000 may be claimed by a new "AirPlay Receiver".
This can be disabled in Settings -> Sharing:
I'm also adding the Screenshot of settings panel for disabling AirPlay Receiver.
Disabling the AirPlay Receiver (if you do not need it) frees up port 5000.

Is there any command line tool to script tcp sockets

I'm playing around with building a MPD client for my private use and came across the following problem.
I need to (from a /bin/sh script):
send a command over tcp to the sever
wait for an OK on a line of its own
send a close command to the server to clean up the connection
Is there any command line tool I can use to do this (I could code it in C/Java/Python but would prefer not to introduce the dependency)
I have tried netcat but am unable to do step 2, which leads to me losing parts of the response from 1 as the connection is closed before the output is sent.
What I tried that did not work all the time was.
printf 'command_list_ok_begin\nnext\nstatus\nplaylistinfo\ncommand_list_end\nclose\n'|nc -w 5 $mpdhost 6600 #

How do I get back to the running instance of riak-shell?

I was in riak-shell when ssh lost its connection to the server. After reconnecting, I do the following:
sudo riak-shell
and get:
An instance of riak-shell is already running
So, I restarted the riak node in question. This did not seem to solve the problem. I do not see anything using ps -aux to kill. According to the docs, only one instance can run at a time. That makes sense, but when I run riak-shell from another node and try to connect to any node, I now get the following:
Error: invalid function call : connection_EXT:connect ["riak#<<<ip_address_elided>>>"]
You can connect to a specific node (whether in your riak_shell.config
or not) by typing 'connect "dev1#127.0.0.1";' substituting your
node name for dev1.
You may need to change the Erlang cookie to do this.
See also the 'reconnect' command.
Unhandled message received is {#Ref<0.0.0.135>,disconnected}
riak-shell(3)>
I have not changed the cookies during this process, and the cookie appears to be the same (at least in /etc/riak/riak_shell.config). (I am running the Riak TS AMI on AWS.)
riak-shell runs in its own Erlang VM - entirely separate from the riak node
(You don't need to run riak-shell from the machine your node is on - it uses the normal riak-erlang-client to talk to riak)
If you you are on a Linux do ps aux | grep riak_shell_app it will give you the process number you need to kill that instance:
08:30:45:~ $ ps aux | grep riak_shell_app
vagrant 4671 0.0 0.3 493260 34884 pts/4 Sl+ Aug17 0:03 /home/vagrant/riak_ee/dev/dev1/erts-5.10.3/bin/beam.smp -- -root /home/vagrant/riak_ee/dev/dev1 -progname erl -- -home /home/vagrant -- -boot /home/vagrant/riak_ee/dev/dev1/releases/2.1.1/start_clean -run riak_shell_app boot debug_off /home/vagrant/riak_ee/dev/dev1/bin/../log/riak_shell/riak_shell -noshell -config /home/vagrant/riak_ee/dev/dev1/bin/../etc/riak
I wrote a good chunk of it so let me know how you got on:
https://github.com/basho/riak_shell/graphs/contributors

Unable to rsync between my server and my Mac

I have a server where I store data from Mac A and Mac B.
I use rsync to keep the files updated between my Macs.
I run the following code unsuccessfully
#!/bin/zsh
# to copy files from my server to my folder
rsync -Pav $Masi:~/private/ ~/Dropbox/Courses/math/
# to copy files from my folder to my server
rsync -Pav ~/Dropbox/Courses/math $Masi:~/private/
I get the following error message
ssh: connect to host port 22: Connection refused
rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
rsync error: unexplained error (code 255) at io.c(600) [receiver=3.0.5]
ssh: connect to host port 22: Connection refused
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(600) [sender=3.0.5]
I have ssh keys in place so the connection should work, since I can use scp without problems.
How can you use rsync between my server and one of my Macs?
I used to do a lot of this. Just ran a test, a few suggestions.
Spell out your entire user#host pattern
Run the ssh connection sans the rsync first, you may need to first approve your fingerprint
You do not seem to pass a flag to protect extended attributes, this can yield broken files on OS X. If you do not need resource forks, you are OK, but most of the time you do need them.
My test case:
$ rsync -Pav ~/Desktop/ me#remote.example.com:~/rsyc-test
In that case, all the files within ~/Desktop were copied to the remote host, in my home dir. Since the directory 'rsyc-test' did not exist, it was made for me. I had a .app on my Desktop, it made it over, surprisingly, it works. Even some .webloc files made it and appear to work, though I do not trust it.
I would strongly suggest adding in the -E flag
-E, --extended-attributes
Apple specific option to copy extended attributes, resource
forks, and ACLs. Requires at least Mac OS X 10.4 or suitably
patched rsync.
I ran a new test, moved a Interarchy bookmark to my desktop, I know for a fact these break if they are copied sans resource forks. Running without the -E versus with the -E, there is a difference of 152 bytes in xfered data. The first file on the remote machine did not work, the second transfered file did work.
I can not help but notice in your example one of your paths is ~/Dropbox so this may all not matter, since DropBox, the app, does not at all support resource forks currently, though I hear there are plans to in the future.
You also are not sending in the --delete flag, if your end goal is a mirror of your data, you are not getting that, if your end goal is backups that continually grows, keeping everything that was ever on the source, the lack of --delete is good.
Other notes:
You can exclude those silly .DS_Store files
--exclude '.DS_Store'
You can also set rsync up in a way to be a true mirror, so you would not need to run your other command, see the man page for details.
My final working command to shove the Desktop of my laptop to a remote machine:
$ rsync -PEav --delete --exclude '.DS_Store' ~/Desktop/ me#remote.example.com:~/rsycn-test
Check "$Masi". Is that the hostname you are trying to reach?
Try the following command to debug it:
rsync -e 'ssh -v' -Pav $Masi:~/private/ ~/Dropbox/Courses/math/
The Connection refused usually happens when there is a connection issue to the remote (e.g. firewall).
In your case the problem is that $Masi variable is empty. If it's not variable, use Masi.
As per this error:
ssh: connect to host port 22: Connection refused
Notice the double space above after the host word.
the connect to host message doesn't say to which host, so you're trying to connect to empty host. So it sound like a typo in the host name.

Resources