Unique process ID variable query via CLI

Hi everyone,

is there any documentation available on whether a specific backup process is given a unique

DUPLICACY_JOB_ID , DUPLICACY_SNAPSHOT_ID , DUPLICACY_REPOSITORY_PATH , or DUPLICACY_JOB_NAME

that can be queried via the CLI? I am asking, as I am trying to have the post and pre scripts differentiate between multiple processes running at the same time. The specific challenge is: how can I tell which backup process currently invokes the script instance.

Duplicacy passes all arguments it received to the script being called:

You could be looking for -comment:

1 Like

Thank you for the info.

With both methods I still seem to have a catch 22 situation:

suppose Process A and Process B. If A is running on its own then there is no problem. All the if statements and loops execute correctly, same when Process B runs on its own, as in both cases I can query for A and get the desired result.

However, consider Process A is running, it passes the pre-check script because only A is being executed. It moves on to doing the backups. Now, Process B commences and executes the pre-check script which queries for A (ps aux | grep A) then now the problem it returns TRUE. Which becomes a problem when Process B (which is much shorter than Process A) executes the post-prune script, and essentially shuts down the remote machine.

My idea was that if there was a way to query which process was currently executing the script then a double check should do the trick: if: Process A is executing script and is querying A: TRUE, else: FALSE.

Is there a way around this behaviour within the limitations of what duplicacy offers? Perhaps I am misunderstanding something

Lets backtrack. What are you trying to acomlish on a high level?

I have been running two backup processes successfully for a long time (A and A'). They were running at different times and never overlapped. A goes to remote server box, A’ to cloud. Whenever a process runs, I start it with the prune and end it with the check commands. This inherently executes the pre-prune and post-check scripts, but because they never ran at the same time, I was able to check if the right process was running ps aux | grep A and then just have the script execute (turn on remote box, and then move files and turn off). So far so good.

The new situation is that the need for a new backup process C arose that runs more frequently and is much faster and shorter than A, it has nothing to do with either the remote box or the cloud backup, and rather is a local buffer backup. However, because it also includes the prune and check commands, it executes the scripts. And this is where I ran into the limitations of checking whether A was running, because C would essentially execute while A was running, and then turning off the remote machine.

That brings us to this discussion

Ok, it makes more sense: to rephrase, you want in the pre- and post- scripts do a certain operation (waking the remote server) only if the bakcup target is remote host.

As I pointed out above, you can find out what is running by inspecting command line arguments passed to the script. To make it even eaiser, you can use @Droolio’s suggestion, and add an additional argument to duplciacy, -comment ..., with some unique data that you could check in your pre-/post- scripts to identify the invocation, and skip or not skip waking the remote machine.

That said, note, that you can run any duplicacy operations concurrently. You can run backup/prune/check sequences to remote box, to the cloud, and C. They are entirely independent, there is no need to sequence them, and therefore any logic in your scripts shoudl not depend on the order or concurrency of these invocation: if it does, it’s a strong idication of some flaw in the logic.

Thank you for that. I think I am getting closer to understanding.

Do you think this is a sound approach?
I have now added a -comment TEST to A, and it looks like this:

duplicacy-unraid:/# ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 bash /usr/local/bin/init.sh
   15 root      0:00 duplicacy_web
   21 root      0:00 tail -0 -f /logs/duplicacy_web.log
  273 root      0:00 bash
  285 root      0:00 /root/.duplicacy-web/bin/duplicacy_linux_x64_3.2.3 -log prune -storage cloud -keep 0:365 -keep 60:180 -keep 30:60 -keep 7:30 -keep 1:7
  326 root      1:53 /root/.duplicacy-web/bin/duplicacy_linux_x64_3.2.3 -log -comment TEST prune -storage remote -keep 0:2560 -keep 365:1100 -keep 90:365 -keep
  401 root      0:08 /root/.duplicacy-web/bin/duplicacy_linux_x64_3.2.3 -log backup -storage local -stats
  434 root      0:00 ps aux

if I indiscriminately ps aux | grep TEST then it will return TRUE as long as that process is running. However, if I look for TEST and prune in the same line then I can have a simple if statement and things should work independently of one another.

That might work, but I’m not sure why are you still looking at all other processes, and not just the current one?

the simpler and cleaner approach is to check what arguments are passed to the current pre- or post- script

if printf "%s\n" "$@" | egrep -q "^-comment=TEST$"; then
  echo "we are inside script called for the job TEST"
else
  echo "we are inside the script but not for the job TEST"
fi

Thank you! That worked beautifully

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.