10 Nov
2023
10 Nov
'23
11:41 a.m.
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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)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
10 Nov
10 Nov
12:45 p.m.
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(a)trinitydesktop.org
--Mike
1:26 p.m.
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:
...
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
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(a)trinitydesktop.org
--Mike 
2:10 p.m.
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
3:14 p.m.
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.
5:52 p.m.
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
11 Nov
11 Nov
11:59 a.m.
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(a)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(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
7:26 p.m.
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
12 Nov
12 Nov
1:33 a.m.
On Fri, 10 Nov 2023 18:41:22 +0700
Ken Heard <kenslists(a)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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)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
179
days inactive
181
days old
8 comments
7 participants
participants (7)
-
E. Liddell -
Ken Heard -
Ken Heard
-
Mike Bird -
phiebie＠drei.at -
Thierry de Coulon -
Махно