Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 0 down vote accepted

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:

   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.

Some background

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:

  • init system
    • plain System V init + posix shell (Slackware, Debian)
    • OpenRC (Gentoo)
    • Upstart (Ubuntu)
    • systemd (many recent distros)
  • distributions environment-setup-policy*
  • details of the particular init script

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/ 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.

share|improve this answer
It worked now by running import command sudo -u <user> import.. – Selcuk Bozdag Mar 31 '14 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.

share|improve this answer
His (homebrew) system V init script managed to take the screen shot. sudo did not. Read the question. It means environment leaked. Intentionally or not. Man pages are general and say nothing about what an individual OS or even script might do. – Ярослав Рахматуллин Mar 31 '14 at 1:30
On the contrary, you should read this answer, which explains why the sudo command did not work, which was that the environment did not leak and the system operated as designed and documented. – JdeBP Mar 31 '14 at 6:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .