Our System V service runs a daemon that runs the import command. Running our service by sudo service myservice start seems to start the service but when it comes to take a screenshot, import does not work. The only way to grab a screenshot is starting service with /etc/init.d/myservice start. Following that, we are able to grab the screenshot with import command.
Any ideas?
There is no straight forward answer to your question, other than "it depends on the environment" i.e. the GNU / Linux distribution.
Before I go into semi-relevant details, you should know that the reason why sudo service import-image-service does not work is because the import command does not have enough information about the environment to know where and how to take the screenshot. Reading man sudo reveals:
DESCRIPTION
sudo allows a permitted user to execute a command as the superuser or
another user, as specified by the security policy.
This is somewhat cryptic and learning about this "security policy" is fun, but perhaps not one of your favourite activities. I give you my word that this means commands started with sudo run in an isolated environment.
In contrast, /etc/init.d/myservice works because environment-setup-policy takes steps to configure some sane defaults such as export DISPLAY=:0.0. You will have to investigate the intricacies of the distribution in use to figure out how to properly inform a service about the presence of an X server. In the mean time, you can try 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.
warning: this section is semi-factual and biased historically
The services in a GNU / Linux system behave somewhat arbitrarily from one distribution to the next. Mostly, the difference is in the setup of the environment before the service is run. This depends on several factors, the most important ones being:
Debian, Slackware and Gentoo (OpenRC) use a conceivably similar approach where /etc/init.d/ services are independent scripts that optionally get additional information from /etc/default/servicename, /etc/conf.d/servicename and similar. The scripts may or may not rely on distribution-specific init-function such as /lib/lsb/init-functions or /lib64/rc/sh/functions.sh. These additional shell libraries may get information (set up the environment) from additional distribution-specific sources.
Ubuntu (Upstart) and systemd have an "entirely" different approach where each service has a configuration file and the init system does all the magic.
To fully understand what's going on, one has to read and understand the init system and the quirks of the distribution in use.
* the process of initializing environment variables and starting a service.
import command sudo -u <user> import..
Mar 31, 2014 at 12:50
This is very clearly explained in the manual page for the Linux old System V service in the very first sentence:
service runs a System V init script in as predictable environment as possible, removing most environment variables and with current working directory set to /.
How do you think that the image command knows where to find your X server? It's the DISPLAY environment variable of course.
Don't rely upon the notion that services run in an interactive login environment with controlling terminals, DISPLAY environment variables, and so forth. They do not. If you've designed a service based upon these assumptions, then you've designed it wrongly, and you've designed something that isn't even working for you now, let alone that will work should you use a different init system such as systemd, upstart, nosh, runit and so forth, all of which ensure that services are not affected by the arbitrary values of an interactive shell's environment variables (and other process state) when a service is brought up/down.
sudo command did not work, which was that the environment did not leak and the system operated as designed and documented.