/etc/environment lacks man page.

Bug #18574 reported by Ralph Corderoy on 2005-06-30
This bug affects 3 people
Affects Status Importance Assigned to Milestone
manpages (Ubuntu)
Nominated for Karmic by Hendy Irawan
Nominated for Lucid by Hendy Irawan

Bug Description

There's no environment(5) man page. No package seems to own it.

    $ dpkg -S /etc/environment
    dpkg: /etc/environment not found.
    $ cat /etc/environment

Without a man page, it's unclear what purpose it has, e.g. at what times
is it read, and what format it has, e.g. are comments allowed, what
about quoting, etc.

Vassilis Pandis (pandisv) wrote :

This is still an issue on 6.06.

Changed in manpages:
status: Unconfirmed → Confirmed
Vassilis Pandis (pandisv) wrote :

And Edgy.

Vassilis Pandis (pandisv) wrote :

And feisty.

Henning Moll (drscott) wrote :

Interesting part from /usr/share/doc/belocs-locales-bin/NEWS.Debian.gz:

> * Locale variables are now stored in /etc/default/locale and no more
> /etc/environment. The reason is that Debian Policy forbids modifying
> configuration files of other packages, and /etc/environment is a
> configuration file for PAM.
> Make sure to remove old definitions from /etc/environment, this file
> is no more modified for the reason explained above.

So the owner should be pam.
locales should not be stored there, but this is still neccessary (e.g. for gdm).

Still in gutsy.

Ralph Janke (txwikinger) wrote :

still in hardy

Allan (allan-stokes) wrote :

still in jaunty

Note: OpenBSD does not consider missing man pages on configuration files to be minor, which is why I continue to enjoy sysadmin under OpenBSD more so than Ubuntu.

This is a sysadmin papercut: a minor defect that could be easily fixed which griefs nearly everyone who has to figure out a permanent place to put JAVA_HOME from what I can tell reading the forums.

From https://help.ubuntu.com/community/EnvironmentVariables

/etc/environment - This file is specifically meant for system-wide environment variable settings. It is not a script file, but rather consists of assignment expressions, one per line. Specifically, this file stores the system-wide locale and path settings.

Does not explain when this file is read, as per the original bug report. And another thing. My preferred shell is zsh, not bash. It would be nice if some of the docs were less bash specific.

Helge Stenström (h-stenstrom) wrote :

In a discussion on a Java application, there was a tip on checking the /etc/environment file (https://bugs.launchpad.net/ubuntu/+source/freemind/+bug/212588). I have the file, but have never changed it myself. It is not owned by a package. I don't dare to change it manually. What if my changes are bad? Perhaps not now, but later on, when my changes are inconsistent with some future policy?

I need to know the proper way to change the file; which environment variables that are OK to put there and which are not. In which circumstances was the file written to begin with?

Hendy Irawan (ceefour) wrote :

Still in 9.10 Karmic Koala.

In addition, LD_LIBRARY_PATH can't get loaded from /etc/environment since Jaunty, see bug #366728

Thank you for posting this bug.

Does this issue occur in Lucid?

Changed in manpages (Ubuntu):
status: Confirmed → Incomplete

On Tue, Sep 14, 2010 at 07:37:27PM -0000, rusivi1 wrote:
> Does this issue occur in Lucid?

Goodness me. Is it so hard to check for the presence of a man page
before asking the reporter? Please don't ask for confirmation of bugs
you can check for yourself.

 status triaged

Changed in manpages (Ubuntu):
status: Incomplete → Triaged
Lesmana Zimmer (lesmana) wrote :

still in lucid

$ dpkg -S /etc/environment
dpkg: /etc/environment not found.
$ man environment
No manual entry for environment

Confirmed same output in Maverick.

 lsb_release -rd
Description: Ubuntu maverick (development branch)
Release: 10.10

apt-cache policy manpages
  Installed: 3.24-1ubuntu1
  Candidate: 3.24-1ubuntu1
  Version table:
 *** 3.24-1ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

Tamlin (storyjesse-gmail) wrote :

I've done a little reading and it appears /etc/environment is indeed a configuration file for Linux-PAM
  man PAM ("PAM" must be in capitals "pam" is something else)

Also had a look at Linux-PAM System Administrators Guide http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_env.html which states that pam_env.so passes the lines in /etc/environment

So when is the pam_env.so loaded?

PAM configuration is in /etc/pam.d/ or /etc/pam.conf (the latter is ignored if the former is present) My Ubuntu system (10.4 upgraded from 6.4) uses /etc/pam.d/
Of the files in this directory atd, cron, gdm, gdm-autologin, login & su require pam_env.so so, going by the names of these config files, I'm guessing that pam_env.so, which loads /etc/environment, is run when gdm is started and at login, perhaps even when cron and atd are run?

I can confirm that /etc/environment is read and the variables set at login and/or su login, but I don't have time right now to test cron or atd, and don't know how to test gdm or gdm-autologin

Hope this helps answer the original question somewhat but I agree it would be nice to know how to execute pam_env.so manually.

One limitation to /etc/environment though is that it is NOT a shell script - it is a config file - and therefore putting the following doesn't work:

this results in
  echo $script_logs

rather than
  echo $script_logs

For this reason I'll probably just put
  source /mnt/config/scripts/myenvar
at the end of /etc/bash.bashrc even though https://help.ubuntu.com/community/EnvironmentVariables says it's not recommended. Then include all my custom global variables in /mnt/config/scripts/myenvar

P.S. I can see why Debian has decided to separate out local variables from /etc/environment as it's not very intuitive to set environment variables through an authentication system. I hope the trend continues and we'll eventually get a standard set of configuration files that all (or at least all compliant) programs reference. :-)

Stéphane Aulery (lkppo) wrote :

The valid page is environ.7, which exists. LANGUAGE variable is not described by environ.7, but it’s an other problem treated in the bug : #311558.

Changed in manpages (Ubuntu):
status: Triaged → Invalid

No, environ(7) documents the "char **environ" symbol that program can expect to find and that contain environment variables. That's not connected to environment(5) that describes a file format for a file that contains environment variables, e.g. are comments allowed. Other problems stated by this bug would also not be fixed by saying environ(7) is the solution, e.g. is /etc/environment owned by a package yet.

Can someone with the rights please set this back Triaged.

Changed in manpages (Ubuntu):
status: Invalid → Confirmed

Also, given a file /etc/foo then one would expect foo to be the name of the man page; not bar. Thus environment(5), not environ(7).

Michael Kerrisk (mtk-manpages) wrote :

The point here is that /etc/environment is a pam_env(8) thing. The pam_env(8) page documents /etc/environment, but users can't easily discover that information. There needs to me a man page "link" , environmen(5), that points to pam_env(8). I filed this report to get that fixed:


Stéphane Aulery (lkppo) wrote :

Oops, dumpling. Sorry. I have no write access to revert me changes.

Colin Watson (cjwatson) on 2016-02-22
Changed in manpages (Ubuntu):
status: Confirmed → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.