找不到Synology Scheduler .sh Java命令

我有一个bash脚本，那就是唯一的任务就是执行一个jar文件。

短信

java -jar /volume1/homes/jar/smssender.jar

使用Synology NAS设置任务。

添加命令以执行bash脚本。添加日志输出。

执行我的新任务。

检查日志以查看以下错误：

/volume1/homes/jar/sms.sh：第1行：java：找不到命令

检查Java版本/安装：

手动检查sh脚本的执行（有效）：

有人遇到同样的奇怪情况吗？任何解决方法/想法？

我试过了

重新启动我的NAS
卸载/安装Java8软件包

但没有一个有效。

java bash synology

— u
source

考虑到您的问题，执行作业时未正确设置env（JAVA_HOME，PATH）可能是一个问题。您要么使用Java可执行文件的绝对路径，要么为您提供源文件。

— NoDataFound

@NoDataFound绝对路径是什么意思？/volume1/(...)/file.jar是路径吗？感谢您的帮助和时间

— piguy

首先，找到java可执行文件。然后，使用/whatever/path/to/java/is/java /volume1/homes/jar（不是特定于

— Synology

我们可能应该在这里添加，无论最终运行命令的用户是不是OP登录的用户（除非他确定是），因此具有不同的PATH。

— BadZen

（也是：这真的是话题吗？）

— BadZen

Answers:

当Synology任务计划程序执行脚本时sms.sh，PATH设置将从script中获取/etc/crontab。其中不包含Java路径。

默认的登录Shell环境定义为int /etc/profile。最后有一节添加Java路径。

PATH=$PATH:/var/packages/Java8/target/j2sdk-image/bin # Synology Java runtime enviroment
PATH=$PATH:/var/packages/Java8/target/j2sdk-image/jre/bin # Synology Java runtime enviroment
JAVA_HOME=/var/packages/Java8/target/j2sdk-image/jre # Synology Java runtime enviroment
CLASSPATH=.:/var/packages/Java8/target/j2sdk-image/jre/lib # Synology Java runtime enviroment
LANG=en_US.utf8 # Synology Java runtime enviroment
export CLASSPATH PATH JAVA_HOME LANG # Synology Java runtime enviroment

正如已经给出的评论中已经提到的那样，不建议采购用于交互式shell的配置文件脚本。您可以在/etc/profile脚本中模仿脚本的行为sms.sh来设置CLASSPATH PATH JAVA_HOME LANG。

在此特定情况下，有关对脚本中的路径进行硬编码以及由此导致的可移植性降低的突出问题可能是情人优先的。

— 次优
source

您的回答对我有很大帮助，而且是正确的，但是我在手机上单击不当，并向下方的用户提供了100分。我真的很抱歉

— piguy

@piguy直播。;-)

— 优

-1

我不熟悉Synology这么晚...

Shell脚本在命令行执行时有效，因为特定的登录会话已经加载了一组环境变量（例如，在登录.profile/.bashrc主目录中的脚本后，将获得源变量并加载各种特定于Java的环境变量- PATH, JAVA_HOME, CLASSPATH等），java并且脚本可以正常运行。

失败的 Synology作业错误表示尚未加载特定于Java的环境变量，因此作业/脚本无法定位java。

假设Synology没有规定预加载登录配置文件的配置设置/标志，那么“简单”的解决方案是sms.sh在执行任何操作（例如，调用java）之前编辑脚本（）并让其获取适当的资源文件。一个简单的例子：

$cat sms.sh
#!/usr/bin/bash

. ~root/.bashrc      # load the root account profile before continuing ...

java ...

笔记：

用root运行脚本的登录名替换（在示例Synology图像中，您选择了root用户，因此我的示例引用~root）
替换~root/.bashrc为用户配置文件的路径，以便预加载允许脚本查找所需的环境变量java

— 马普索
source

请不要鼓励为交互使用而编写的配置文件在非交互上下文中使用-这会导致人们认为他们.bashrc所做的更改是无害的（因为不会更改守护程序的运行方式，对吗？）而是会导致生产中断。

— Charles Duffy

更好的方法是找到实际位置，然后在脚本本身或脚本来源的专用配置文件中对相应的PATH更新进行硬编码。这也适用于情况下这不会- F / E，当/etc/profile.d而非~/.bashrc是相关的。

— Charles Duffy

硬编码很难移植，尤其是在混合OS /版本环境中；至于使用交互式配置/资源文件还是特制的资源/配置文件……这更多是基于开发人员编写/维护环境的个人选择问题；在过去的20年中，我一直没有/零问题……在生产环境中……在整个脚本环境ymmv中使用通用的资源/配置文件

— markp-fuso

在用户的交互式文件中添加点也不是可移植的（特别是考虑到发行版如何重新平衡哪些文件是由哪些文件完成的-有些是以传统方式进行操作和使用的.profile，有些是使用的.bash_profile，有些是使用的/etc/profile.d，有些是通过PAM设置环境变量的，等等）。一种或另一种方式，您正在做一些不可移植的事情。至少硬编码PATH=$PATH:/whatever/specific/location正在修改设置，并且它的行为对于读者来说是显而易见的（读者不必担心它是否会在以后更改）。

— Charles Duffy