In mid-October last I installed in a desktop computer Debian Bookworm and TDE. After the installation I was able successfully to transfer the source of the operating system from the CD disk to the built-in source. After opening the OS from the local source I installed an application and was able to use it. I also made some adjustments to the TDE ‘kicker’. I then closed the computer for the night. The next morning I expected to open the computer without difficulty. So I opened it and got as far as the ‘Login to TDE’ window. I entered my password. Instead of opening the TDE I received the following message:
Call to lnusertemp failed (temporary directories full ?). Check your installation.
As of this point the only access I had to the computer was by a ‘console login’. Fortunately I had a spare laptop without any operating system installed. I consequently installed on it the same OS and TDE. This time I did not receive the message quoted above. In time I was able to install all the applications I wanted and adjust the kicker and other TDE features to my liking. While I have been using the laptop for several weeks now, I would like to be able to use the desktop.
I did however do an online search; all I found were a few posts about this message dated on average ten years ago. A few made reference to the possible absence of KDE files, a diagnosis which I did not think relevant. Others made reference to having the right permissions. Without however complete access to the desktop it was difficult to check permissions of ‘temporary directories’. Directories which appeared to me relevant and where I was able to see the permissions in both computers, all were identical.
I cannot understand why what appears to me as identical installations in both computers would not work in both. How can I ‘check the installation’ if access to the computer is so restricted?
All help, suggestions, etc. will be gratefully received.
Ken Heard
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Fri November 10 2023 03:41:22 Ken Heard via tde-users wrote: ...
The next morning I expected to open the computer without difficulty. So I opened it and got as far as the ‘Login to TDE’ window. I entered my password. Instead of opening the TDE I received the following message:
Call to lnusertemp failed (temporary directories full ?). Check your installation.
As of this point the only access I had to the computer was by a ‘console login’.
...
I cannot understand why what appears to me as identical installations in both computers would not work in both. How can I ‘check the installation’ if access to the computer is so restricted?
Hi Ken,
You could start by running "df" and then "df -i" from the console login to see if any partition is indeed full.
The console login requires fewer resources and thus can run on systems that are temporarily unable to supprt a full windowing GUI interface.
BTW, I hope you can see this reply. It looks like you tried to contact us through an old address. The current list address is: users@trinitydesktop.org
--Mike
On 2023-11-10 19:45, Mike Bird via tde-users wrote:
On Fri November 10 2023 03:41:22 Ken Heard via tde-users wrote: ...
The next morning I expected to open the computer without difficulty. So I opened it and got as far as the ‘Login to TDE’ window. I entered my password. Instead of opening the TDE I received the following message:
Call to lnusertemp failed (temporary directories full ?). Check your installation.
As of this point the only access I had to the computer was by a ‘console login’.
...
I cannot understand why what appears to me as identical installations in both computers would not work in both. How can I ‘check the installation’ if access to the computer is so restricted?
Hi Ken,
You could start by running "df" and then "df -i" from the console login to see if any partition is indeed full.
The console login requires fewer resources and thus can run on systems that are temporarily unable to supprt a full windowing GUI interface.
BTW, I hope you can see this reply. It looks like you tried to contact us through an old address. The current list address is: users@trinitydesktop.org
--Mike
Thanks for the reply. Both commands df and df -i showed no partition or directory anywhare near 100% full.
Thanks also the change of address.
Ken
On Friday 10 November 2023 14.26:04 Ken Heard via tde-users wrote:
Thanks for the reply. Both commands df and df -i showed no partition or directory anywhare near 100% full.
This is pure guesswork based on previous experiences:
a) Do you install "the Windows Way", I mean on a single partition? b) You write that you installed several applications. Did you encouter any install failures?
I you can, try to look at the size of the files in yout home directory, there might be a file like "xerrors" or so taking all the space.
I had that long time ago: an install goes wrong. Linux writes the error protocol to a file, then tries the install again, it fails, etc.., and the error file grows. At some point the system crashes or you shut it down. Then, at the next start, the system does not find enough space to create its log file and can't start a graphical system.
If so, the only solution is either to find and delete that giant file at the command line, or to start from a live system and do the same.
That's why I always install with a separate home partition AND setup TDE to allow root login: such error logs are written to home, and as root's "home" is not on the home partition, you can cure teh problem from root.
Thierry
Hi Thierry de Coulon via tde-users,
Am 10.Nov.2023 um 15:10 schrieben Sie:
I you can, try to look at the size of the files in yout home directory, there might be a file like "xerrors" or so taking all the space.
The file is called .xsession-errors (mind the . at the beginning). This monster indeed grows and grows and I have not yet found the culprit. Solution: a cronjob daily just before I shutdown the system with [rm -f .....] and the spook is gone.
Regards, Peter.
On Friday 10 November 2023 16.14:16 phiebie--- via tde-users wrote:
The file is called .xsession-errors (mind the . at the beginning).
Yep, that's it. But *any* file that is created in home and fills the space would have the same result (for example some stuck copy routine or (I got that too) a video capture software that (as most do) uses ~ as temp directory.
That's why I avoid the one-partition-for-everything solution. It's easy to link other partitions to home directories.
This monster indeed grows and grows and I have not yet found the culprit. Solution: a cronjob daily just before I shutdown the system with [rm -f .....] and the spook is gone.
Well, mine is only a few KB (today) and seems to be recreated at boot. I did not do anything. I don't think this is a TDE stuff, so maybe it depends on the distribution settings (MX-Linux here).
Thierry
Hello.
If it already happened that you ran out of disk space and using the du -k /home | sort -n | tail -5 command you were able to determine that the .xsession-errors file is the one that takes up more space, the first step to fix the problem is to empty it completely:
$ >~/.xsession-errors
Once the space is freed, you will want this situation not to be repeated again in the future. To achieve this it is best to try to find the origin of the problem, ie, to know which process is writing uncontrolled to the error log and why.
If you want to forget about this log because in normal operation you are not interested in its debugging information, you can redirect to /dev/null everything that is written to it and thus always keep a size of 0 bytes. For this you can delete the .xsession-errors file and create a symbolic link to /dev/null instead in order to get the same result:
$ rm .xsession-errors $ ln -s /dev/null .xsession-errors
The problem is that when you restart the session the symbolic link will be replaced back by a regular file and will start to grow again. To avoid this you must add the following lines to the .bashrc in your home directory:
# If the .xsession-errors file is not a symbolic link, delete it and create it as such if [ ! -h $HOME/.xsession-errors ]; then /bin/rm $HOME/.xsession-errors ln -s /dev/null $HOME/.xsession-errors fi
2023-11-10, pn, 19:53 Thierry de Coulon via tde-users users@trinitydesktop.org rašė:
On Friday 10 November 2023 16.14:16 phiebie--- via tde-users wrote:
The file is called .xsession-errors (mind the . at the beginning).
Yep, that's it. But *any* file that is created in home and fills the space would have the same result (for example some stuck copy routine or (I got that too) a video capture software that (as most do) uses ~ as temp directory.
That's why I avoid the one-partition-for-everything solution. It's easy to link other partitions to home directories.
This monster indeed grows and grows and I have not yet found the culprit. Solution: a cronjob daily just before I shutdown the system with [rm -f .....] and the spook is gone.
Well, mine is only a few KB (today) and seems to be recreated at boot. I did not do anything. I don't think this is a TDE stuff, so maybe it depends on the distribution settings (MX-Linux here).
Thierry ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
Reminder that Ken has already said he is not out of disk space or inodes.
Hopefully a devel can suggest other possible causes of "lnusertemp failed" during login.
--Mike
On Fri, 10 Nov 2023 18:41:22 +0700 Ken Heard kenslists@teksavvy.com wrote:
I did however do an online search; all I found were a few posts about this message dated on average ten years ago. A few made reference to the possible absence of KDE files, a diagnosis which I did not think relevant. Others made reference to having the right permissions. Without however complete access to the desktop it was difficult to check permissions of ‘temporary directories’. Directories which appeared to me relevant and where I was able to see the permissions in both computers, all were identical.
Was ~/.trinity (your user's TDE settings directory) among those whose permissions and ownership you checked? Use "ls -l [parent dir] | grep [target]" (for instance, "ls -l /usr | grep tmp" to get the information for /usr/tmp) to pull out only the information for the directories you're interested in.
Have you tried running starttde from the command line to see what specific errors it produces, if any?
E. Liddell
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
-
E. Liddell -
Ken Heard -
Ken Heard
-
Mike Bird -
phiebie＠drei.at -
Thierry de Coulon -
Махно