导致命令在运行服务时失败的原因

我们的System V服务运行一个运行import命令的守护进程。通过sudo service myservice启动运行我们的服务似乎启动了服务，但是当涉及到截屏时，导入不起作用。获取屏幕截图的唯一方法是使用/etc/init.d/myservicestart 启动服务。接下来，我们可以使用import命令获取屏幕截图。

有任何想法吗？

你的问题没有直接的答案，除了“它取决于环境”，即GNU / Linux发行版。

在我进入半相关细节之前，您应该知道原因sudo service import-image-service不起作用的原因是导入命令没有足够的环境信息来了解截屏的位置和方法。阅读男子sudo揭示：

 DESCRIPTION
   sudo allows a permitted user to execute a command as the superuser or
   another user, as specified by the security policy.

这有点神秘，了解这个“安全政策”很有趣，但也许不是你最喜欢的活动之一。我告诉你，这意味着在一个孤立的环境中以sudo运行的命令。

相比之下，/etc/init.d/myservice因为environment-setup-policy采取步骤来配置一些合理的默认值，例如export DISPLAY=:0.0。您将不得不调查正在使用的分发的复杂性，以弄清楚如何正确地通知服务有关X服务器的存在。同时，你可以试试sudo -E service myservice

  -E      The -E (preserve environment) option indicates to the secu‐
       rity policy that the user wishes to preserve their existing
       environment variables.  The security policy may return an
       error if the -E option is specified and the user does not
       have permission to preserve the environment.

一些背景

警告：这部分是历史上的半事实和偏见

GNU / Linux系统中的服务从一个发行版到下一个发行版表现得有些随意。大多数情况下，不同之处在于在运行服务之前设置环境。这取决于几个因素，最重要的因素是：

• init系统
  • plain System V init + posix shell（Slackware，Debian）
  • OpenRC（Gentoo）
  • 新贵（Ubuntu）
  • systemd（许多最近的发行版）
• 分发环境设置策略*
• 特定init脚本的详细信息

Debian，Slackware和Gentoo（OpenRC）使用一种可以想象的类似方法，其中/etc/init.d/服务是独立的脚本，可以选择从/ etc / default / servicename，/ etc / conf.d / servenename等获取附加信息。这些脚本可能依赖于或不依赖于特定于发行版的init函数，例如/ lib / lsb / init-functions或/lib64/rc/sh/functions.sh。这些额外的shell库可以从其他特定于分发的源获取信息（设置环境）。

Ubuntu（Upstart）和systemd有一种“完全”不同的方法，每个服务都有一个配置文件，而init系统可以完成所有的魔术。

要完全了解正在发生的事情，必须阅读并理解init系统和正在使用的分发的怪癖。

*初始化环境变量和启动服务的过程。

service在第一句话的Linux旧系统V的手册页中非常清楚地解释了这一点：

service 在尽可能可预测的环境中运行System V init脚本，删除大多数环境变量，并将当前工作目录设置为/。

你怎么认为image命令知道在哪里找到你的X服务器？这DISPLAY当然是环境变量。

不要依赖于服务在具有控制终端，DISPLAY环境变量等的交互式登录环境中运行的概念。他们不。如果你设计基于这些假设一个服务，那么你就错设计的，和你设计的东西，甚至没有为你工作，现在，更何况，将工作，你应该使用不同的init系统，如systemd，upstart，nosh，runit等等，所有这些都确保服务在启动/关闭服务时不受交互式shell的环境变量（和其他进程状态）的任意值的影响。