在 Hudson 调用的脚本中运行时 cp 命令失败
这是一款益智游戏。如果我从命令行运行命令来远程复制文件，它就可以正常工作。如果我在服务器（托管 Hudson）上的脚本内运行相同的命令，它也可以完美运行，与从命令行以 hudson 运行作业相同。但是，如果我从 Hudson 作业中以 bash 脚本内的函数运行该确切命令，则会失败：
cp: cannot stat '/opt/flash_board.tar.gz': No such file or directory
变量定义为：
original_tarball=flash_board.tar.gz
并且在范围内（变量扩展在脚本中正常工作）。
原始命令是：
ssh -n -o stricthostkeychecking=no root@$IP_ADDRESS ssh -n -o stricthostkeychecking=no 169.254.0.2 cp /opt/$original_tarball /opt/$original_tarball.bak
我也尝试过：
ssh -n -p 1601 -o stricthostkeychecking=no root@$IP_ADDRESS cp /opt/$original_tarball /opt/$original_tarball.bak
它指向正确的端口，但以完全相同的方式失败。
作为参考，所有变量均已检查为有效。我最初认为这是一个替换错误，但事实似乎并非如此，所以我尝试使用 Hudson 凭据运行它：
sudo -u hudson ssh -n -o stricthostkeychecking=no root@$IP_ADDRESS ssh -n -o stricthostkeychecking=no 169.254.0.2 cp /opt/$original_tarball /opt/$original_tarball.bak
我得到了完全相同的结果（它有效）。因此，只有当该命令从 Hudson 作业运行时才会失败。
以下是事件的顺序：
- Hudson 作业设置参数&调用 shell 脚本。
- 脚本内的函数尝试通过 SPI 总线将文件从嵌入式 Montevista (Linux) 板远程复制到第二个嵌入式 Arago (Linux) 板。
- 两块板物理上位于同一主板上，但无法直接访问Arago 板，除非通过串行控制台会话（这是不可行的，这是跨网络运行的自动化作业）。
我已经尝试使用 ssh 和 -p 1601 （Arago 端的正确端口）。
我可以使用 scp 将远程文件复制到与具有不同文件扩展名的远程文件相同的位置吗？
比如：
scp -o stricthostkeychecking=no root@$IP_ADDRESS /opt/$original_tarball /opt/$original_tarball.bak
我让几个开发人员看了一下这个，他们也被难住了。任何人都有任何想法（A）为什么会失败& (B) 如何解决这个问题。我很确定我可以编写一个脚本在远程计算机上本地运行，但这似乎没有必要。
哦，如果我在 Montevista 板上运行完全相同的命令（这意味着我不必穿过 SPI 总线 (169.254.0.2)），它就可以在 Hudson 作业中完美运行。
This one is a puzzler. If I run a command from the command line to copy a file remotely it works perfectly. If I run that same command inside a script on the server (that hosts Hudson), it runs perfectly as well, same for running the job as hudson from the command line. However, if I run that exact command as a function inside a bash script from a Hudson job, it fails with:
cp: cannot stat '/opt/flash_board.tar.gz': No such file or directory
The variable is defined as:
original_tarball=flash_board.tar.gz
and is in scope (variable expansion works correctly in the script).
The original command is:
ssh -n -o stricthostkeychecking=no root@$IP_ADDRESS ssh -n -o stricthostkeychecking=no 169.254.0.2 cp /opt/$original_tarball /opt/$original_tarball.bak
I've also tried it as:
ssh -n -p 1601 -o stricthostkeychecking=no root@$IP_ADDRESS cp /opt/$original_tarball /opt/$original_tarball.bak
which points to the correct port, but fails in exactly the same way.
For reference all the variables have been checked to be valid. I originally thought this was a substitution error, but that doesn't seem to be the case, so then I tried running it with Hudson credentials as:
sudo -u hudson ssh -n -o stricthostkeychecking=no root@$IP_ADDRESS ssh -n -o stricthostkeychecking=no 169.254.0.2 cp /opt/$original_tarball /opt/$original_tarball.bak
I get the exact same results (it works). So it's only when this command is run from a Hudson job that it fails.
Here's the sequence of events:
- Hudson job sets parameters & calls a shell script.
- A function inside the script tries to copy the files remotely from an embedded Montevista (Linux) board across an SPI bus to a second embedded Arago (Linux) board
- Both boards are physically on the same mother board, but there's no way to directly access the Arago board except through a serial console session (which isn't feasible, this is an automation job that runs across the network).
I've tried this using ssh with -p 1601 (the correct port to the Arago side).
Can I use scp to copy a remote file to the same location as the remote file with a different file extension?
Something like:
scp -o stricthostkeychecking=no root@$IP_ADDRESS /opt/$original_tarball /opt/$original_tarball.bak
I had a couple of the devs take a look at this and they were stumped as well. Anyone got any ideas (A) why this fails & (B) how to work around it. I'm pretty sure I can write a script to run locally on the remote machine, but that doesn't seem like it should be necessary.
Oh, and if I run the exact same command on the Montevista board (which means I don't have to go across the SPI bus (169.254.0.2), it works perfectly from the Hudson job.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
所以，事实证明这与问题完全无关。我用测试 Hudson 脚本将问题分解为小块，从原始脚本中增加了越来越多的复杂性，直到它像以前一样失败。
事实证明这是飞行员错误，我编写了一个
if语句来区分两个板（Arago 和 Montevista），然后抽象出传递给if的变量> 语句到传入哪个板不明确的地步，因此if逻辑总是抓住第一个匹配项（理应如此）以及我试图在 Arago 板上复制的 Flash 脚本Montevista 董事会上不存在（嗯，它有一个不同的名称）所以返回的错误是绝对正确的。很抱歉让您陷入困境，并感谢您付出的一切努力。
So, this turned out to be something completely unrelated to the question. I broke the problem down into little pieces with a test Hudson script, adding more and more complexity from the original script till it failed as before.
It turned out to be pilot error, I'd written an
ifstatement to differentiate between the two boards (Arago & Montevista) and then abstracted out the variables passed to theifstatement to the point where it was ambiguous which board was being passed in, so theiflogic always grabbed the first match (as it should) and the flash script I was trying to copy on the Arago board didn't exist on the Montevista board (well, it has a different name) so the error returned was absolutely correct.Sorry for the spin up and thanks for all the effort to help.
这表示 Hudson 无法看到该文件。我会在你的 shell 脚本中执行
ls -la /opt。这将显示/opt目录的权限，以及您的脚本是否可以列出该文件。当您执行此操作时，也在 Hudson 计算机上执行
du -f并查看该/opt目录是否是远程安装或可能有问题的目录。您已经说过，您以运行 Hudson 任务的用户身份登录并从工作区目录执行它。
现在，我怀疑目录权限是一个问题。
This is saying that Hudson cannot see the file. I would do a
ls -la /optin that shell script of yours. This will show you the permissions on the/optdirectory, and whether your script can list that file.While you're at it, do a
du -fon the Hudson machine too and see if that/optdirectory is a remote mount or something that could be problematic.You've already said that you logged in as the user that runs the Hudson task and execute it from the workspace directory.
Right now, I suspect that the directory permission is an issue.
出现错误的明显原因是它在错误的机器上运行，可能是由于行长度限制或奇怪的引用问题。
我会尝试将命令更改为
... uname -a或... hostname -f来查看是否获得了正确的机器。或者，... cp /proc/cpuinfo /tmp/this-machine然后查看哪台机器获取该文件。编辑：我现在看到OP已经回答了他自己的问题。我想我会把它留在这里，以防它对任何遇到类似问题的未来访客有所帮助。我想我应该在可能发生这种情况的原因中添加“或不运行您正在运行的命令”。
The obvious way that goes wrong is that somehow it is being run on the wrong machine, possibly due to either a line length limit, or to weird quoting issues.
I'd try changing the command to
… uname -aor… hostname -fto see if you get the right machine. Or, alternatively,… cp /proc/cpuinfo /tmp/this-machineand then see which machine gets the file.edit: I see now that OP has answered his own question. I guess I'll leave this here in case it helps any future visitors with similar issues. I guess I should add "or not running the command you thing you're running" to the reasons why it could happen.