Then afterward it should fallback on tmp if there is no variable set. I don't have this set either.

I always just assumed that people mounted their tmpfs on /tmp...

Either way /tmp is standard

I don't know the correct solution to fix KDM. I only know the way things should work. :)

Yes, the fallback should be hard-coded to /tmp, but if $TMP, $TEMP, $TMPDIR are defined in the environment, then any TDE app looking for temporary file storage locations should use those locations.

TDE does do this, just not KDM.

I create a tmpfs on my system in fstab. In my environment I have $TEMP, $TMP, and $TMPDIR mapped to my tmpfs location.

TDE correctly uses those locations. Traditionally, TDE (and formerly KDE3) uses three temporary file locations:

$KDEHOME/cache-$HOSTNAME --> /var/tmp/kde3cache-$USER
$KDEHOME/socket-$HOSTNAME --> /tmp/kde3socket-$USER
$KDEHOME/tmp-$HOSTNAME --> /tmp/kde3--$USER

The FHS says that /var/tmp is an appropriate for persistent temporary data (needs to survive reboots) and /tmp is appropriate for non-persistent temporary data.

When $TMP, $TEMP, or $TEMPDIR are defined the non-persistent location of /tmp changes to $TMP. I think this happens at the operating system level.

KDM runs without user account knowledge. Hard-coding to /tmp seems to make sense, but if $TMP is a globally defined variable then KDM should be using tmpfs and not /tmp.

Perhaps take a look at how $KDEHOME/socket-$HOSTNAME and $KDEHOME/tmp-$HOSTNAME are defined in the code. kdelibs/kdecore/ktempfile.h provides the code for the name of the user's temp directories, but I don't know where the sym link to $TMP is created (ktempfile.cpp?).

I hope this helps. :)

Thank you for the lengthy response :-)

Here is the issue at hand I think, KDM is started as root, typically by the init daemon or whatever your distro uses (upstard, sysvinit, etc).

It is started as root, runs as root, as it should.

Assuming we fixed thids, I still don't see where this variable comes into play at all. How would one even set a temporary variable before they login! Unless you hardcoded the TEMP variable into your start script it would be pointless. 

Wouldn't a better solution be to have KDM config option that modifies the KDM TEMP location?

I think that is saner.

 - Calvin Morrison

Yeah, I alluded previously to KDM running as non-user. :)

Of course, none of the $TMP variables are set because until now I always have been thinking like a user and have those variables set in an /etc/profile.d script. Those scripts are sourced only during a login.

The same is true for /etc/profile. The variables can't be set there either.

I ran a quick test by temporarily setting the variables in my rc.local. At the end of my rc.local script I ran 'set > /tmp/variables.txt' to grab a picture of the environment before anybody logged in. I then rebooted into graphical mode.

I logged in using ssh. I verified the $TMP variables are being set in the system environment. Yet KDM is still using /tmp rather than the environment variables.

With that said, I rebooted to a command line login and noticed the /tmp files were gone. Apparently on shutdown or reboot KDM does some housecleaning -- although not perfect because there were some stale dcop socket files in /tmp/.ICE-unix.

Is this a big deal? No, yet I think the bug report remains valid. As I mentioned, TDE does know about the environment variables because the sym links to tmpfs are correctly set with the user's profile temp directories. KDM needs to do the same thing.

I don't like the idea of hard-coding those locations in kdmrc. :) The KDM code should detect the environment variables just like the user temp directories.

When using TDM I notice many temp files in /tmp, most of which use a numerical directory name. These directories are created by TDM and are profile directories. TDM performs no housekeeping. Actually the opposite. Every time a user logs in/out and returns to TDM, TDM creates one of these numerical profile directories in /tmp. I see no purpose for TDM creating these profile directories. They were not needed in KDE3 and were not created in KDE3.

(In reply to comment #5)
> When using TDM I notice many temp files in /tmp, most of which use a numerical
> directory name. These directories are created by TDM and are profile
> directories. TDM performs no housekeeping. Actually the opposite. Every time a
> user logs in/out and returns to TDM, TDM creates one of these numerical profile
> directories in /tmp. I see no purpose for TDM creating these profile
> directories. They were not needed in KDE3 and were not created in KDE3.

After patching tdm a few days ago I have not noticed this problem, or it has been reduced in severity such that I have not yet had a recurrence.  Can you confirm with latest GIT sources?

Also, isn't this bug a duplicate of Bug 974 ?

(In reply to comment #7)
> Also, isn't this bug a duplicate of Bug 974 ?

To clarify, I am referring to comment #5 as seeming to belong to Bug 974 instead of Bug 625 .

There is overlap but two distinct issues.

I don't know what can be done about using /tmp as a hard-coded the default rather than $TMP ($TMDIR and $TEMP too). For the latter to succeed the environment variables need to be defined before any user logs in. I don't know how many distros do that. If I understand correctly, if $TMP/$TEMP/$TMPDIR are defined before TDM starts, then the underlying TDE code will use those variables.

At least that is the behavior I see for users. I have $TMP defined when a user logs in. My TDE user profile temporary directories are created in $TMP rather than /tmp. I don't know whether this behavior applies to non-user usage too.

Some people and distros use tmpfs and map /tmp to tmpfs. Therefore the files there get destroyed with every reboot. This method assures a "lazy" way of performing some basic system cleanup. Yet not all people or distros do this. Not all people reboot daily or even regularly.

The profile directories addressed in bug report 974 is different. Although these too are hard-coded to /tmp, they should not be created in the first place. TDM does not need a profile directory to function.

I'm rebuilding tdebase and will report later on all the latest results. :-)

(In reply to comment #9)
> There is overlap but two distinct issues.
> 
> I don't know what can be done about using /tmp as a hard-coded the default
> rather than $TMP ($TMDIR and $TEMP too). For the latter to succeed the
> environment variables need to be defined before any user logs in. I don't know
> how many distros do that. If I understand correctly, if $TMP/$TEMP/$TMPDIR are
> defined before TDM starts, then the underlying TDE code will use those
> variables.
> 
> At least that is the behavior I see for users. I have $TMP defined when a user
> logs in. My TDE user profile temporary directories are created in $TMP rather
> than /tmp. I don't know whether this behavior applies to non-user usage too.

There are other problems to consider here as well.  For instance, certain privileged processes leave sockets in tmp so that non-privileged processes can interact with them.  How can you make absolutely sure that the user's $TMPDIR always matches root's $TMPDIR?  If they don't match up, strange things may happen.

> Some people and distros use tmpfs and map /tmp to tmpfs. Therefore the files
> there get destroyed with every reboot. This method assures a "lazy" way of
> performing some basic system cleanup. Yet not all people or distros do this.
> Not all people reboot daily or even regularly.
> 
> The profile directories addressed in bug report 974 is different. Although
> these too are hard-coded to /tmp, they should not be created in the first
> place. TDM does not need a profile directory to function.

I would like to clear this up once and for all.  The old *unmanaged* tdm does not need these "profile directories", which as of the latest GIT HEAD only consist of a handful of DCOP sockets, to run, you are correct there.  However, the new tdm, which provides managed windows, DOES need at least those minimal sockets to run.  The managed windows feature was warmly welcomed by the userbase, so reverting it completely is not an option.

It is possible that you are referring to ksycoca entries, in which case you are correct.  However, ksycoca entries should no longer be created by TDM in the latest GIT sources.

Yes, I agree there are other issues to consider. That was what I meant when I wrote "I don't know what can be done about using /tmp as a hard-coded default...."

I'm not hard-core about this particular bug report. My own understanding about the inner workings of this hugely complicated environment has grown since filing this bug report. I understand that temp files have to go somewhere. :-)

Regarding the "managed windows," I am not asking that the work be undone nor am I questioning that value. I accept that this new process needs work space to function and that location is /tmp by default. My concern with bug report 974 is the accumulation of the nominal profile directories.

To me, a profile directory is not a socket file. If I am misunderstanding then I welcome help with the terminology. :-) Perhaps when you write "socket" you include these nominal profile directories. Perhaps the creation of these profile files can't worked around.

I will address the profile directories in bug report 974. I just started testing with the latest patches. Possibly the problem is now resolved. :-)

This particular bug report can be closed --- although I welcome clarification about using the term "socket." :-)

(In reply to comment #11)
> This particular bug report can be closed --- although I welcome clarification
> about using the term "socket." :-)

A socket file in this context is a (usually empty) file that processes use to communicate with each other.  An example would be the various .DCOP files you have seen in the /tmp directory.

That part I understand. Thanks. With a file manager/browser, the files usually are demarked in some kind of way and usually zero bytes. They serve as a conduit for data to move back and forth.

I don't understand how the nominal profile directories fit into the scheme. Specifically, those file are not socket files, correct?

BTW, I posted an update to bug report 974 regarding the creation of those profile files.

Unless there are reasons otherwise, we can close this bug report as Invalid.

How did that old song go? Let it be, let it be....