Unable to schedule a recurring Unison job with cron or gnome-schedule

[Robert E. Vanderhoof]

I'm trying to sync a folder across two machines at regular intervals on a local network using Unison with this command:
     unison RogStuff -batch
I can run the Unison job from the command line without problem.
When I schedule the job as a one-time event in Gnome-schedule it runs without problem.
When I run the job manually from Gnome-schedule's Configure Scheduled Tasks window it runs without problem
When I schedule the job as a recurring task in Gnome-schedule IT DOES NOT WORK..
However, if I schedule local folders to be synced with Unison they will run as a recurring task.

[GauteHope (eg)]

I am unfamiliar with Unison, but it might be an issue with the authentication method you are using to access the remote machines? Otherwise, is it a graphical program? Does other graphical programs work on as recurrently scheduled tasks?

- Gaute

[Robert E. Vanderhoof (nv4yjcooy-robert)]

Nothing graphical. Using ssh but runs fine from command line and as a one-time task.

Sent from my MOTOROLA ATRIX™ HD on AT&T

GauteHope <email address hidden> wrote:

>I am unfamiliar with Unison, but it might be an issue with the
>authentication method you are using to access the remote machines?
>Otherwise, is it a graphical program? Does other graphical programs work
>on as recurrently scheduled tasks?
>
>- Gaute
>
>--
>You received this bug notification because you are subscribed to the bug
>report.
>https://bugs.launchpad.net/bugs/1097504
>
>Title:
> Unable to schedule a recurring Unison job with cron or gnome-schedule
>
>Status in “gnome-schedule” package in Ubuntu:
> New
>
>Bug description:
> I'm trying to sync a folder across two machines at regular intervals on a local network using Unison with this command:
> unison RogStuff -batch
> I can run the Unison job from the command line without problem.
> When I schedule the job as a one-time event in Gnome-schedule it runs without problem.
> When I run the job manually from Gnome-schedule's Configure Scheduled Tasks window it runs without problem
> When I schedule the job as a recurring task in Gnome-schedule IT DOES NOT WORK..
> However, if I schedule local folders to be synced with Unison they will run as a recurring task.
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/ubuntu/+source/gnome-schedule/+bug/1097504/+subscriptions

[GauteHope (eg)]

How do you authenticate with ssh? If by ssh-agent that might be an issue.

[Robert E. Vanderhoof (nv4yjcooy-robert)]

I use shared RSA keys.

Quoting GauteHope <email address hidden>:

> How do you authenticate with ssh? If by ssh-agent that might be an
> issue.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1097504
>
> Title:
> Unable to schedule a recurring Unison job with cron or gnome-schedule
>
> Status in “gnome-schedule” package in Ubuntu:
> New
>
> Bug description:
> I'm trying to sync a folder across two machines at regular
> intervals on a local network using Unison with this command:
> unison RogStuff -batch
> I can run the Unison job from the command line without problem.
> When I schedule the job as a one-time event in Gnome-schedule it
> runs without problem.
> When I run the job manually from Gnome-schedule's Configure
> Scheduled Tasks window it runs without problem
> When I schedule the job as a recurring task in Gnome-schedule IT
> DOES NOT WORK..
> However, if I schedule local folders to be synced with Unison they
> will run as a recurring task.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gnome-schedule/+bug/1097504/+subscriptions
>

[GauteHope (eg)]

Try to create a wrapper script which sets up an ssh-agent and adds the key, something like this:

  #! /bin/bash
  eval $(ssh-agent)
  ssh-add ~/.ssh/your_rsa_key
  unison_command

and launch that script as a recurrent (cron) job.

- Gaute

[Robert E. Vanderhoof (nv4yjcooy-robert)]

Greetings,

I appreciate your help with this. I've tried your script and it worked
flawlessly. May I trouble you further for an explaination as to why the
script works and simply scheduling the job does not.

Thanks,

Robert Vanderhoof

On 01/11/2013 03:22 AM, GauteHope wrote:
> Try to create a wrapper script which sets up an ssh-agent and adds the
> key, something like this:
>
> #! /bin/bash
> eval $(ssh-agent)
> ssh-add ~/.ssh/your_rsa_key
> unison_command
>
> and launch that script as a recurrent (cron) job.
>
> - Gaute
>

[GauteHope (eg)]

The reason is that for keys to work with ssh an ssh-agent implementation (ssh-agent, gnome-keyring, etc) needs to be accessible
by the ssh client. When you run your window manager an agent is set up which is normally able to automatically determine which key needs to be loaded and then load it if it does not have a password. This is why it works without you needing to do anything in your normal environment.

The agent information is stored in environment variables and references to a communication pipe some where on the filesystem, usually in /tmp/ (changing file name each time the agent is started -> when you log in), where only your user has access.

When running a cron job you do not have access to your usual environment and any programs run as a cron job (recurrent) does not know where to communicate with any existing (ssh)agent - if you are logged in at the time. So, since your keys do not require any passwords or interactive input, starting an ssh-agent and exporting the access information (environment variables using 'eval'), adding the key to this agent (ssh-add), the programs (utilizing an ssh client) run in this environment will know how to access the newly started agent (probably running parallel to any other agent you have running on your login session).

It is similar to relaying the ssh-agent information when you log in remotely using the '-A' flag of ssh, this way the remote session (e.g. command line bash) will have access to the original ssh-agent on your local machine through a pipe set up through the ssh connection - with the result that you can use the keys of your original agent in any further ssh connections made from the remote computer (current session).

As to why this is not done through gnome-schedule; there are infinite many ways various program interact with each other - creating wrapper scripts like this is easier. The only exception where we try to support interaction is between a program and the currently running graphical environment - by again exporting the environment variables to the X session and authority agents. Remember that cron and at was created without graphical environments and will run even if you are not logged in or have a graphical environment set up. If the application needs a graphical environment and there is none - it is likely to crash.

I hope I was clear enough, and I am happy to help,
- Gaute

Quoting:
> Greetings,
>
> I appreciate your help with this. I've tried your script and it worked flawlessly. May I trouble you further for an explaination as
> to why the script works and simply scheduling the job does not.
>
> Thanks,
>
> Robert Vanderhoof

[Robert E. Vanderhoof (nv4yjcooy-robert)]

Your articulate explanation is much appreciated. Makes sense now. I
will file our exchange away for future reference. Thanks again.

On 01/11/2013 07:33 AM, GauteHope wrote:
> The reason is that for keys to work with ssh an ssh-agent implementation (ssh-agent, gnome-keyring, etc) needs to be accessible
> by the ssh client. When you run your window manager an agent is set up which is normally able to automatically determine which key needs to be loaded and then load it if it does not have a password. This is why it works without you needing to do anything in your normal environment.
>
> The agent information is stored in environment variables and references
> to a communication pipe some where on the filesystem, usually in /tmp/
> (changing file name each time the agent is started -> when you log in),
> where only your user has access.
>
> When running a cron job you do not have access to your usual environment
> and any programs run as a cron job (recurrent) does not know where to
> communicate with any existing (ssh)agent - if you are logged in at the
> time. So, since your keys do not require any passwords or interactive
> input, starting an ssh-agent and exporting the access information
> (environment variables using 'eval'), adding the key to this agent (ssh-
> add), the programs (utilizing an ssh client) run in this environment
> will know how to access the newly started agent (probably running
> parallel to any other agent you have running on your login session).
>
> It is similar to relaying the ssh-agent information when you log in
> remotely using the '-A' flag of ssh, this way the remote session (e.g.
> command line bash) will have access to the original ssh-agent on your
> local machine through a pipe set up through the ssh connection - with
> the result that you can use the keys of your original agent in any
> further ssh connections made from the remote computer (current session).
>
> As to why this is not done through gnome-schedule; there are infinite
> many ways various program interact with each other - creating wrapper
> scripts like this is easier. The only exception where we try to support
> interaction is between a program and the currently running graphical
> environment - by again exporting the environment variables to the X
> session and authority agents. Remember that cron and at was created
> without graphical environments and will run even if you are not logged
> in or have a graphical environment set up. If the application needs a
> graphical environment and there is none - it is likely to crash.
>
> I hope I was clear enough, and I am happy to help,
> - Gaute
>
> Quoting:
>> Greetings,
>>
>> I appreciate your help with this. I've tried your script and it worked flawlessly. May I trouble you further for an explaination as
>> to why the script works and simply scheduling the job does not.
>>
>> Thanks,
>>
>> Robert Vanderhoof

[GauteHope (eg)]

With pleasure,

Gaute