git push在cron作业中不起作用 [英] git push not working inside a cron job

问题描述

我目前正在清理CentOS 6服务器上其他人留下的一团糟.有一个应用程序需要每6小时备份到github帐户.有一个脚本负责准备数据，并负责git add和git commit.

I am currently cleaning up a mess left by someone else on a CentOS 6 server. There is an application that is required to be backed up to a github account every 6 hours. There is a script that takes care of preparing the data and it takes care of the git add and git commit.

git推送由"expect"脚本处理.这样做是为了在ssh要求将密码短语传递给git push时使用.用户不想使用空密码.

The git push is taken care of by an "expect" script. This was done so that the passphrase can be passed to the git push when the ssh asks for it. The user does not want to use an empty passphrase.

当root用户在bash shell中从命令行运行脚本时，脚本运行良好.我可以看到文件已传输到github.

The script runs fine when run from the command line in a bash shell by the root user. I can see the files transferred to github.

当脚本在由root创建的crontab下运行时，脚本似乎可以运行，但是git push不会发生.如果我手动运行git push，则在脚本失败后，我会注意到应该发生的推送与我从命令行调用的手动一起发生.似乎应该在脚本中进行的推送已被缓存，而不是推送到github.

When the script runs under a crontab created by root the script appears to run but the git push does not take place. If I manually run a git push, after the script has failed, I notice that the push that should have happened happens along with the manual one I have called from the command line. It appears that the push that should have happened in the script has been cached and not pushed to github.

有人可以建议我在这里缺少什么吗?是否可以通过git push在这样的脚本中工作?

Can anyone suggest what I am missing here? Is it possible to get a git push to work within a script like this?

致谢

理查德

推荐答案

问题应该出在git push尝试运行时，ssh-agent未正确将密码传递给ssh.

The issue should be in the passphrase being not correctly passed by the ssh-agent to ssh when the git push tries to run.

如后续说明所示博客帖子，您不能简单地在cron中调用 ssh-agent -s ，否则，它只会创建另一个实例，且其中没有键.

As illustrated by the follow-up blog post, you cannot simply call ssh-agent -s in your cron, or it would simply create another instance, with no key in it.

要解决此问题，我需要找到一种方法来阻止启动另一个 ssh-agent 进程，而是在每次登录时获得对一个海马启动的访问权限.
我对crontab进行了更改，将搜索现有的ssh-agent进程ID和身份验证套接字并将其导入cron环境.这是一种hack，但实际上可以(不像上次那样).
只需在尝试连接到SSH服务器之前将以下内容添加到您的脚本中即可(或执行我所做的操作，然后将它们直接放在cron作业中，并用分号分隔):

To fix it, I needed to find a way to keep from starting another ssh-agent process, and instead gain access to the one seahorse starts every time I log in.
I made a change to my crontab that would search for the existing ssh-agent process ID and authentication socket and import them into the cron environment. This is kind of a hack but it actually works (not like last time).
Just add the following to your script before trying to connect to your SSH server (or do what I did and put them right into the cron job, separated by semicolons):

export SSH_AGENT_PID=`ps -a | grep ssh-agent | grep -o -e [0-9][0-9][0-9][0-9]`
export SSH_AUTH_SOCK=`find /tmp/ -path '*keyring-*' -name '*ssh*' -print 2>/dev/null` 

要澄清:

只需将以下内容添加到您的脚本中

Just add the following to your script

这意味着以上两行是声明为cron作业并由该cron作业调用的脚本的一部分.

That means the above two lines are part of a script declared as a cron job and called by said cron job.

将它们直接放入cron作业中，并用分号隔开

put them right into the cron job, separated by semicolons

如果脚本足够小，则可以完全摆脱该脚本，并使cron作业成为一系列命令:请参阅"使用crontab运行两个命令.

If the script is small enough, you can get rid of the script entirely and make your cron job a sequence of commands: see "Run two commands with a crontab".

crontab -l | { cmd1; cmd2 ; cmd3; } | crontab -

该语法只是您以编程方式向作业添加 命令的一种方式.

That syntax is but one of the way you can add programmatically a command to a cron job.

这篇关于git push在cron作业中不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！