Bug 981373
| Summary: | XFCE4 desktop hangs if TMPDIR is set | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Corinna Vinschen <vinschen> |
| Component: | coreutils | Assignee: | Ondrej Oprala <ooprala> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | admiller, kdudka, kevin, kzak, ooprala, ovasik, p, twaugh, vinschen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-19 14:35:25 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Is there anything in ~/.xsession-errors (or whereever kdm outputs stdout)? Can you do a 'strace -f -p pidofnewest-xfdesktopprocess' and attach it? Might tell us what it's doing. I'll see if I can duplicate it here. Hi Kevin,
I investigated a bit further, and inspecting the ~/.xsession-errors as
you suggested gave the final clue. It's a bit more convoluted than what
I observed in the first place. The culprit is not xfce4 (the same problem
also disallows to start a KDE desktop), but the coreutils package.
Here's what happens:
My .login file does not set the TMP, TEMP and TMPDIR vars independently,
rather it's setting them like this:
setenv TMP /home/corinna/tmp
setenv TEMP ${TMP}
setenv TMPDIR ${TMP}
After a failed login, ~/.xsession-errors contained the following message:
(xfce4-session:5710): xfce4-session-WARNING **: Unable to open temporary file: Failed to create file '/tmp/.colorlsDyZ/.xfsm-ICE-XCSRZW': Not a directory
Note the weird temporary path. There's no /tmp/.colorlsDyZ directory.
A bit of grep'ing turned up the /etc/profile.d/colorls.csh file, which
sets the TMP variable to the name of a temporary /tmp/.colorlsXXX file.
The file is removed at the end of the script, but the TMP variable is
not. Since the TMP variable in this script is a tcsh-internal variable,
not an environment variable, it is preferred over the TMP environment
variable (different variable concept than in sh/bash). The result is
that the above `setenv TMPDIR ${TMP}' will set TMPDIR to the value of
the internal TMP variable, rather than the value of the environment
variable TMP, thus TMPDIR is set to /tmp/colorlsDyZ rather than
/home/corinna/tmp.
This is a bug in the /etc/profile.d/colorls.csh script, which is part of
the coreutils package.
Given that colorls.csh is a profile script, it's run in the login shell
process itself. The value of TMP will not be forgotten at the end of the
script, and given its name it's bound to break settings like the one in
my environment.
As far as I can see, the /etc/profile.d/colorls.csh should not use the
TMP variable name for the temporary filename, but rather something
non-dangerous like $_tmp. It should also definitely call `unset' on the
variable when finished.
For some reason I can't change the "Component" of this bug from xfdesktop
to coreutils, the drop-down menu is grayed out. Can you change that?
Thanks,
Corinna
Excellent detective work. Thanks! Hi and thanks for the report. I've changed the variable to a less collision-prone one (the proposed _tmp) and pushed the changes to rawhide. Since this have been here without a response for almost a year, I'm assuming the bugfix is satisfactory. |
Description of problem: This occurs after upgrade from F18. Logging in at the DM, startxfce4 is called and some XFCE4 processes are started per `ps -fu' output. However, xfce4 seems to get stuck at one point , and the desktop stays empty. Mouse pointer is visble and can be moved, but nothing else happens. I'm tcsh user. I have a user-local ~/tmp directory and the environment variables TMP, TEMP, and TMPDIR are set to ~/tmp in ~/.login. The ~/tmp dir has 755 permissions, user and group are set as expected (user/primary group). My display manager is KDM, but the same effect can be reproduced with GDM. SELinux setting (enforced/permissive/disabled) is irrelevant, the effect doesn't depend on the setting and can be reproduced. The problem can be worked around by *not* setting TMPDIR in ~/.login. This didn't occur under F18. Version-Release number of selected component (if applicable): xfdesktop-4.10.2-1.fc19.x86_64 How reproducible: Create ~/tmp. Set TMPDIR to ~/tmp in environment. Use Steps to Reproduce: 1. Choose XFCE4 as desktop environment 2. Choose tcsh as login shell 3. Create ~/tmp. 4. Set TMPDIR in ~/.login to ~/tmp 5. Login at the graphical desktop. Actual results: XFCE4 desktop is started, but stays invisible. Expected results: Normal startup behaviour Additional info: Here's the output of `ps -fucorinna' after the login, with TMPDIR set: UID PID PPID C STIME TTY TIME CMD corinna 1253 1 0 09:51 ? 00:00:00 /usr/bin/gpg-agent --sh --daemon --write-env-file /home/corinna/.cache/gpg-agent-info corinna 1274 1269 0 09:51 tty2 00:00:00 -tcsh corinna 2129 1 0 09:54 ? 00:00:00 /usr/bin/pulseaudio --start corinna 2170 2129 0 09:54 ? 00:00:00 /usr/libexec/pulse/gconf-helper corinna 27124 1 0 16:01 ? 00:00:00 /usr/bin/gnome-keyring-daemon --daemonize --login corinna 27126 27038 0 16:01 ? 00:00:00 -/bin/tcsh -c startxfce4 corinna 27140 1 0 16:01 ? 00:00:00 dbus-launch --sh-syntax --exit-with-session corinna 27141 1 0 16:01 ? 00:00:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session corinna 27207 1 0 16:01 ? 00:00:00 /usr/libexec/imsettings-daemon corinna 27210 1 0 16:01 ? 00:00:00 /usr/libexec/gvfsd corinna 27215 1 0 16:01 ? 00:00:00 /usr/libexec//gvfsd-fuse -f /run/user/500/gvfs corinna 27221 1 0 16:01 ? 00:00:00 /usr/lib64/xfce4/xfconf/xfconfd corinna 27287 27126 0 16:01 ? 00:00:00 /usr/bin/ssh-agent /bin/sh -c exec -l /bin/tcsh -c "startxfce4" corinna 27309 27126 0 16:01 ? 00:00:00 /bin/sh /etc/xdg/xfce4/xinitrc corinna 27315 27309 0 16:01 ? 00:00:00 xfce4-session corinna 27318 27315 0 16:01 ? 00:00:00 xfwm4 --display :0.0 --sm-client-id 291391704-85f8-4398-87ad-7424b3fff2cc corinna 27325 27315 0 16:01 ? 00:00:00 xfce4-panel --sm-client-id 2f84127f1-7d72-40ca-a108-9cd27dfff711 corinna 27331 27315 0 16:01 ? 00:00:00 xfdesktop --display :0.0 --sm-client-id 22fc502c6-fb37-49ad-b347-4082fdfc8858 corinna 27334 27315 0 16:01 ? 00:00:00 xfdesktop --display :0.0 --sm-client-id 22fc502c6-fb37-49ad-b347-4082fdfc8858 corinna 27336 27315 0 16:02 ? 00:00:00 xfdesktop --display :0.0 --sm-client-id 22fc502c6-fb37-49ad-b347-4082fdfc8858 corinna 27338 27315 0 16:02 ? 00:00:00 xfdesktop --display :0.0 --sm-client-id 22fc502c6-fb37-49ad-b347-4082fdfc8858 corinna 27339 27315 0 16:02 ? 00:00:00 xfdesktop --display :0.0 --sm-client-id 22fc502c6-fb37-49ad-b347-4082fdfc8858 corinna 27340 1274 0 16:02 tty2 00:00:00 ps -fucorinna As you can see, there are multiple xfdesktop processes, started from the xfce4-session. After a normal working desktop startup, there's only one xfdesktop process left. So these xfdesktop processes are apparently waiting for some synchronization event which doesn't happen. Just a guess... If you need any other data, I'm glad to provide it. Thanks, Corinna