rsync - how do I run commands 1 after another? - rsync

I want to run multiple commands. They don't need to run at the same time. Just run command 1, then command 2, etc.
rsync -az -P live/ test1/
rsync -az -P live/ test2/
Is there a way to do this without waiting for the first command to finish and then entering the second command?

Easy,
rsync -az -P live/ test1/; rsync -az -P live/ test2/
This will run test1 wait, then run test2.

Run them as background processes using &:
rsync -az -P live/ test1/ &
rsync -az -P live/ test2/ &
They are now running in the background! Should output something like:
[4] 9434
for each, where
[4] is used to get the process back to the foreground using fg 4 (i.e., running in the foreground in the shell); press CTRL+Z to pause it. Then to resume and start again in the background using bg 4.
9434 is the PID.

Related

Moving a file with rsync works at the command line, but not in cron

I'm working on a home automation system using a Raspberry Pi. As part of this, I'd like the rPi to pull a file from my web server once a minute. I've been using rsync, but I've run into an error I can't figure out.
This command works fine when run at the command line on my rPi:
rsync -avz -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress username#example.com:/home/user/example.com/cmd.txt /home/pi/sprinkler/input/cmd.txt
...but when it runs in cron, it produces this error in my log:
Unexpected local arg: /home/pi/sprinkler/input/
If arg is a remote file/dir, prefix it with a colon (:).
rsync error: syntax or usage error (code 1) at main.c(1375) [Receiver=3.1.2]
...and I just answered my own question. Extensive googling around didn't turn up an answer but I just tried putting my rsync command into a bash script, and running the script in cron instead of the command and now everything works!
I'll put this here in case anyone else stumbles over this issue. Here's a script I called "sync.sh"
#!/bin/bash
# attempting a bash shell to use rsync to grab our file
rsync -avz -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null"
--progress user#example.com:/home/user/example.com/vinhus/tovinhus
/cmd.txt /home/pi/sprinkler/input/

Rsyncing both ways while handling deletes

Right now, I am currently running rsync in two different ways:
rsync -r -avz --delete --progress -e "ssh -p 8443" root#<my_server>:~/app ~/Desktop/;
rsync -r -avz --progress -e "ssh -p 8443" ~/Desktop/app root#<my_server>:~/app/
Obviously the problem here is that if a file doesn't exist on the server, then it gets deleted locally. So if you created a file locally after it synchronized to the server, the first command will run and delete it again locally. If you switch the --delete option to the other command, then the reverse happens.
I've tried experimenting and researching this to do it a few different ways, but I cannot seem to come around to a way that synchronizes changes on both sides depending on what happened first.
An alternative that I saw was Unison, but I have errors with this as well when the version doesn't match between the client and the server.

How can I execute a command after screen exits

launching rsync in named screen so I can reattach to check progress, how can I run a command after the rsync, as is it launches the screen then immediately executes the command?
screen -dmS name rsync
ssh user#hostname 'rm -r ~/path/*'
I'm trying to delete the symlinks of file copied by the rsync,, kind of a "copy once" I don't want to delete source files though.
I suggest running the command inside screen. You could do this by creating a shell script, but in this case the sh -c trick should be sufficient.
screen -dmS name sh -c "rsync args_go_here; ssh user#hostname 'rm -r ~/path/*'"

Tmux: How do I find out the currently running version of tmux?

I know that I can run tmux -V to find the version of tmux that is in my PATH, but how can I get the version of tmux that is currently running?
As pointed out in a comment, tmux -V returns the version:
$ tmux -V
tmux 3.0a
Tested on Centos 7 and OSX 12.5.
Most obvious, but not 100% correct way is to execute this command in console
$ tmux -V
and receive output like this tmux 2.9a with version of tmux INSTALLED, not currently running.
In 99% cases it is enough, but there can be subtle nuances.
Command tmux -V will return version of tmux installed at /usr/bin/tmux or any other directory inside your PATH variable. If you have tmux already running, it is possible that tmux can be started from binary of other version and from different place (for example, tmux can be started from /home/user/bin/tmux).
In this case, you have to call
$ ps -e | grep tmux
to see PID of all tmux processes currently running. It will output something like this
[vodolaz095#ivory ~]$ ps -e | grep tmux
19699 pts/0 00:00:00 tmux: client
19701 ? 00:00:00 tmux: server
Here, number 19701 depicts process id (PID) of currently running tmux server.
After getting PID of tmux server, you can ran command
$ lsof -p 19701
to get information about CURRENTLY RUNNING tmux server process (in my case its 19701) that will output something like this (Figure 1)
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tmux:\x20 19701 vodolaz095 cwd DIR 8,33 4096 22544385 /home/vodolaz095
tmux:\x20 19701 vodolaz095 rtd DIR 8,1 4096 2 /
tmux:\x20 19701 vodolaz095 txt REG 8,1 677760 3675332 /usr/bin/tmux
tmux:\x20 19701 vodolaz095 mem REG 8,1 6406312 131327 /var/lib/sss/mc/group
as you can see, tmux currently running was executed from binary placed in /usr/bin/tmux.
Or, you can call one liner
lsof -p `pgrep 'tmux: server'`
to achieve the same output as Figure 1
After you get path to tmux binary CURRENTLY RUNNING, (in my case, it was /usr/bin/tmux), you can execute this binary with flag -V to get its version
/usr/bin/tmux -V
or, if tmux was installed by limited user into /home/user/bin/tmux,
/home/user/bin/tmux -V
And, as result, you'll get version of tmux currently running, not the one, that was installed.
To get the version of the tmux server you can use display-message.
./tmux2.3 display-message -p "#{version}"
Will show the version of the server (2.7 in my case)
-p will direct the output of stdout so you can script with it and {version} can be anything from the FORMATS section in the man page.
The following will give you the executable of your tmux server, on linux:
realpath /proc/$(tmux display-message -p "#{pid}")/exe
And on macos, proc_pidpath can be used, see https://stackoverflow.com/a/8149380
To find the actual version of the tmux that is running, you have to find the PID of the tmux:
pgrep tmux
With this info, you can check the version by running:
lsof -p $tmuxPID | grep REG | grep -i -e deleted -e "tmux$"
If there is not a (deleted) next to the tmux file listed, you can just run that file with a -V.
If it results in files that are "(deleted)", you are running an old, uninstalled version. If you are on linux, you can figure out what it is by running:
/proc/$tmuxPID/exe -V`
If you are on OS X, you are stuck with whatever information is in the path to the filename, possibly something like Cellar/tmux/<version number>/bin/tmux.
You can combine many of these steps into the following one-liner:
for tmuxPID in $(pgrep tmux); do lsof -p $tmuxPID | grep REG | grep -i -e deleted -e "tmux$"; done
Or if you are on Linux, this always works:
for tmuxPID in $(pgrep tmux); do /proc/$tmuxPID/exe -V; done

Run a service automatically in a docker container

I'm setting up a simple image: one that holds Riak (a NoSQL database). The image starts the Riak service with riak start as a CMD. Now, if I run it as a daemon with docker run -d quintenk/riak-dev, it does start the Riak process (I can see that in the logs). However, it closes automatically after a few seconds. If I run it using docker run -i -t quintenk/riak-dev /bin/bash the riak process is not started (UPDATE: see answers for an explanation for this). In fact, no services are running at all. I can start it manually using the terminal, but I would like Riak to start automatically. I figure this behavior would occur for other services as well, Riak is just an example.
So, running/restarting the container should automatically start Riak. What is the correct approach of setting this up?
For reference, here is the Dockerfile with which the image can be created (UPDATE: altered using the chosen answer):
FROM ubuntu:12.04
RUN apt-get update
RUN apt-get install -y openssh-server curl
RUN curl http://apt.basho.com/gpg/basho.apt.key | apt-key add -
RUN bash -c "echo deb http://apt.basho.com precise main > /etc/apt/sources.list.d/basho.list"
RUN apt-get update
RUN apt-get -y install riak
RUN perl -p -i -e 's/(?<=\{http,\s\[\s\{")127\.0\.0\.1/0.0.0.0/g' /etc/riak/app.config
EXPOSE 8098
CMD /bin/riak start && tail -F /var/log/riak/erlang.log.1
EDIT: -f changed to -F in CMD in accordance to sesm his remark
MY OWN ANSWER
After working with Docker for some time I picked up the habit of using supervisord to tun my processes. If you would like example code for that, check out https://github.com/Krijger/docker-cookbooks. I use my supervisor image as a base for all my other images. I blogged on using supervisor here.
To keep docker containers running, you need to keep a process active in the foreground.
So you could probably replace that last line in your Dockerfile with
CMD /bin/riak console
Or even
CMD /bin/riak start && tail -F /var/log/riak/erlang.log.1
Note that you can't have multiple lines of CMD statements, only the last one gets run.
Using tail to keep container alive is a hack. Also, note, that with -f option container will terminate when log rotation happens (this can be avoided by using -F instead).
A better solution is to use supervisor. Take a look at this tutorial about running Riak in a Docker container.
The explanation for:
If I run it using docker run -i -t quintenk/riak-dev /bin/bash the riak process is not started
is as follows. Using CMD in the Dockerfile is actually the same functionality as starting the container using docker run {image} {command}. As Gigablah remarked only the last CMD is used, so the one written in the Dockerfile is overwritten in this case.
By using CMD /bin/riak start && tail -f /var/log/riak/erlang.log.1 in the Buildfile, you can start the container as a background process using docker run -d {image}, which works like a charm.
"If I run it using docker run -i -t quintenk/riak-dev /bin/bash the riak process is not started"
It sounds like you only want to be able to monitor the log when you attach to the container. My use case is a little different in that I want commands started automatically, but I want to be able to attach to the container and be in a bash shell. I was able to solve both of our problems as follows:
In the image/container, add the commands you want automatically started to the end of the /etc/bash.bashrc file.
In your case just add the line /bin/riak start && tail -F /var/log/riak/erlang.log.1, or put /bin/riak start and tail -F /var/log/riak/erlang.log.1 on separate lines depending on the functionality desired.
Now commit your changes to your container, and run it again with: docker run -i -t quintenk/riak-dev /bin/bash. You'll find the commands you put in the bashrc are already running as you attach.
Because I want a clean way to have the process exit later I make the last command a call to the shell's read which causes that process to block until I later attach to it and hit enter.
arthur#macro:~/docker$ sudo docker run -d -t -i -v /raid:/raid -p 4040:4040 subsonic /bin/bash -c 'service subsonic start && read -p "waiting"'
WARNING: Docker detected local DNS server on resolv.conf. Using default external servers: [8.8.8.8 8.8.4.4]
f27229a260c9
arthur#macro:~/docker$ sudo docker ps
[sudo] password for arthur:
ID IMAGE COMMAND CREATED STATUS PORTS
35f253bdf45a subsonic:latest /bin/bash -c service 2 days ago Up 2 days 4040->4040
arthur#macro:~/docker$ sudo docker attach 35f253bdf45a
arthur#macro:~/docker$ sudo docker ps
ID IMAGE COMMAND CREATED STATUS PORTS
as you can see the container exits after you attach to it and unblock the read.
You can of course use a more sophisticated script than read -p if you need to do other clean up, such as stopping services and saving logs etc.
I use a simple trick whenever I start building a new docker container. To keep it alive, I use a ping in the entrypoint script.
So in the Dockerfile, when using debian, for instance, I make sure I can ping.
This is btw, always nice, to check what is accessible from within the container.
...
RUN DEBIAN_FRONTEND=noninteractive apt-get update \
&& apt-get install -y iputils-ping
...
ENTRYPOINT ["entrypoint.sh"]
And in the entrypoint.sh file
#!/bin/bash
...
ping 10.10.0.1 >/dev/null 2>/dev/null
I use this instead of CMD bash, as I always wind up using a startup file.

Resources