Bug 218143 - /etc/kde/env/env.sh is not being exec'd when user=root
/etc/kde/env/env.sh is not being exec'd when user=root
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kdebase (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ngo Than
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-01 19:16 EST by Gene Heskett
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-26 08:34:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gene Heskett 2006-12-01 19:16:28 EST
Description of problem:
The env var that lists the paths to be used by kbuildsycoca, as set in
~/kde/env/env.sh is not being set/exported properly.  The net result is that a
run of kbuildsycoca misses and removes large section of the k-menu.


Version-Release number of selected component (if applicable):
Current FC6 kdebase package.

How reproducible:

Startx as root, add a program with yumex, in this case xmms and xmms*, then run
kbuildsycoca (also as root) in an attempt to add the new program to the menu's.
The menu's will lose all the admin stuffs, the games will not be subsorted,
kde's control center will be missing, among other things.  And the program is
not added to the menu.

Steps to Reproduce:
1. See above
2.
3.
  
Actual results:
crippled menu's.


Expected results:
program added to menu.


Additional info:

I've added a line to set a junk var and export it in /etc/kde/env/env.sh in an
effort to see if it showed up in an env report, it does not, so I have to assume
this file is not being sourced at boot time, or at startx time when running as
root, which I generally do as usual operating procedure here.

I've added the missing env var to my ~/.bashrc, and that works correctly, and my
menu's are now correct, but this sure seems like a kludge to me.

Selinux is disabled as it, even when set permissive, still prevents amanda,
installed from a tarball as I'm a tester, from running.  I have lots of firewall
upstream so I am not too concerned.
Comment 1 Rex Dieter 2006-12-01 23:13:36 EST
> The env var that lists the paths to be used by kbuildsycoca, as set in
> ~/kde/env/env.sh is not being set/exported properly. 

From discussion on the lists, I think we concluded that XDG_CONFIG_DIRS gets set
properly for non-root users (good), root, however, ends up with an empty
XDG_CONFIG_DIRS (bad).  Therein lies the problem.

I'll see if I can (hopefully) reproduce this on my fc6 boxen on Monday.
Comment 2 Rex Dieter 2006-12-01 23:16:08 EST
> Startx as root, add a program with yumex, in this case xmms and xmms*, then run
> kbuildsycoca (also as root) in an attempt to add the new program to the menu's.

Did you run that kbuildsycoca *inside* the kde session?  If not, that's the
source of the problem.

In general, you should never have to manually run kbuildsycoca (new apps should
appear automatically without manual intervention), and if you ever do run it by
hand, you need to be careful to do it right. (:
Comment 3 Gene Heskett 2006-12-02 00:48:25 EST
Did you run that kbuildsycoca *inside* the kde session?  If not, that's the

yes, kde was running everytime I tried that.
Comment 4 Rex Dieter 2006-12-04 10:00:26 EST
Cannot confirm, WORKSFORME.  

Whether logging in via kdm or just startx, whether a normal user or root, 
$ echo $XDG_CONFIG_DIRS
always returned
/etc/kde/xdg:/etc/xdg

Not sure why that's not working for you with root login.
Comment 5 Rex Dieter 2007-01-26 08:34:11 EST
At this point, since we're unable to reproduce and since it WORKSFORME (and
most/all? other folks), I'll go ahead and mark this as such.

If you can provide details on how to reliably reproduce, feel free to reopen.

Note You need to log in before you can comment on or make changes to this bug.