Hi, On one account on my OpenSuSE Leap 42.3 system (the main account, of course), I'm getting these messages after the login screen and before the desktop appears:
1)
The R14-xdg-update script has been run at least once. The script is not successfully updating. The script will run with each login until corrected. Please contact an administrator or take appropriate administrative action to correct the problem. The error code is 9.
2)
Some Trinity profile R14 XDG compliance updates failed. Check applications-tdemenuedit.menu for '<filename>kde-' in /var/tmp/kdecache-leslie/r14-xdgupdate-validation-test-9.tct.
3)
The R14-xdg-update script has been run at least once. The script is not successfully updating. The script will run with each login until corrected. Please contact an administrator or take appropriate administrative action to correct the problem. The error code is 9. Common failures include file and directory permissions.
(These messages are displayed using xmessage, and can't be copied/pasted since the desktop isn't active, so the above is my hand-copied version, which has all the words, but not necessarily on the same lines.)
So I looked into the indicated file, and indeed there are a plethora of lines containing <filename>kde-... (see attached). Apparently there are 'file and directory permissions' problems /somewhere./ I have looked at the permissions of all files in ~/.kde and they look okay (but is owner rw- sufficient?) I looked at the r14-xdg-update script, but the code is opaque (at least to me). I tried renaming ~/.kde to something else but the problem persists; also tried removing socket-dir and tmp-dir, but that doesn't help either. The script contains this unhelpful comment:
# This script should be needed to run only once, but corner cases # and file/directory permissions could cause incomplete updates. # # TODO: How to handle environments where files/directories are locked # administratively or are owned by root and can't be updated. # The nominal validation checks in this script provide some notice # but no direct remedy. # # TODO: How to update profile directories not named $HOME/.trinity and
$TDEHOME
# is not yet declared when running this script.
I'm not at all sure where to look and what to look for beyond this. How can I get past this irritating situation?
Leslie
Leslie Turriff composed on 2018-04-24 18:32 (UTC-0500):
So I looked into the indicated file, and indeed there are a plethora of lines containing <filename>kde-... (see attached). Apparently there are 'file and directory permissions' problems /somewhere./ I have looked at the permissions of all files in ~/.kde and they look okay (but is owner rw- sufficient?)
I would suspect it should not be sufficient. Virtually all other files in /opt/trinity/bin are world executable. Maybe it doesn't need to be because r14-xdg-update calls it at session start? Needing it for each session start seems to be why Kate's suggestion didn't stick.
Why it only happens with one user would suggest it would not be a problem with /opt/trinity/bin/kxdglauncher permissions, which dates to last July here. Maybe take a look at /etc/group to see if all users are in any groups that might be relevant to a TDE session. If you navigate through $HOME, is everything owned and grouped by the problem user?
Is there anything obvious in /var/log/tdm.log?
I cannot reproduce xsession errors on the system I tested, but do see a few in .xsession-errors. Do your errors vanish if /opt/trinity/bin/kxdglauncher is made world executable? Likely this needs to goto the trinity-devel list if it doesn't help, or maybe goto IRC and ask Slavek about those permissions.
On 2018-04-24 21:44:10 Felix Miata wrote:
Leslie Turriff composed on 2018-04-24 18:32 (UTC-0500):
So I looked into the indicated file, and indeed there are a plethora of lines containing <filename>kde-... (see attached). Apparently there are 'file and directory permissions' problems /somewhere./ I have looked at the permissions of all files in ~/.kde and they look okay (but is owner rw- sufficient?)
I would suspect it should not be sufficient. Virtually all other files in /opt/trinity/bin are world executable. Maybe it doesn't need to be because r14-xdg-update calls it at session start? Needing it for each session start seems to be why Kate's suggestion didn't stick.
Why it only happens with one user would suggest it would not be a problem with /opt/trinity/bin/kxdglauncher permissions, which dates to last July here.
I agree; and /opt/trinity/bin/kxdglauncher has world execution permissions. The messages from r14-xdg-update, though, are very vague. 'file and directory permissions' doesn't tell us if they are read, write or execute permisssions, or if they are owner, group or other permissions. :-(
Maybe take a look at /etc/group to see if all users are in any groups that might be relevant to a TDE session. If you navigate through $HOME, is everything owned and grouped by the problem user?
I have found and corrected erroneous group settings on three files, but I'm still getting the error messages when running r14-xdg-update. I tried tree -apugfi --noreport ~/.kde | grep -v '^[.rw' but got no matches, so all of the owner privileges are R/W; but we don't know if that's sufficient for r14-xdg-update's purposes.
Is there anything obvious in /var/log/tdm.log?
There are a few messages with tde or TQ prefixes, but they don't seem pertinent. I have attached the tail of the log file.
I cannot reproduce xsession errors on the system I tested, but do see a few in .xsession-errors. Do your errors vanish if /opt/trinity/bin/kxdglauncher is made world executable? Likely this needs to goto the trinity-devel list if it doesn't help, or maybe goto IRC and ask Slavek about those permissions.
I don't see anything pertinent in any of my .xsession-errors files.
Now, this is interesting. I accidentally ran r14-xdg-update on the new test account that I had created, and now when I logout and login again with that new account, it also exhibits the same r14-xdg-update infection.
Leslie
On Wed, 25 Apr 2018 18:18:24 -0500 Leslie Turriff jlturriff@mail.com wrote:
Now, this is interesting. I accidentally ran r14-xdg-update on the new test account that I had created, and now when I logout and login again with that new account, it also exhibits the same r14-xdg-update infection.
Okay, if you just want to shut the thing up for these accounts and don't care whether or not the updates are performed, try opening ~/.trinity/share/config/kdeglobals in a text editor for each user, see if there's a section [R14 XDG Updates], create it if there isn't, and stick the following values in it:
Updated=true Version=201412270
(it's possible you may need to increment the Version key to some larger value before this works.)
If that doesn't work, the nuclear option is to edit the starttde script to prevent the updater from being called--comment out everything from
if [ -d "$tdehome" ]; then # Run some R14 updates.
to
# Please see tdestartupconfig source for usage.
to do that.
Hope that helps.
E. Liddell
Yes! This worked for both accounts. Thank you very much.
Leslie
On 2018-04-25 21:24:05 E. Liddell wrote:
On Wed, 25 Apr 2018 18:18:24 -0500
Leslie Turriff jlturriff@mail.com wrote:
Now, this is interesting. I accidentally ran r14-xdg-update on the new test account that I had created, and now when I logout and login again with that new account, it also exhibits the same r14-xdg-update infection.
Okay, if you just want to shut the thing up for these accounts and don't care whether or not the updates are performed, try opening ~/.trinity/share/config/kdeglobals in a text editor for each user, see if there's a section [R14 XDG Updates], create it if there isn't, and stick the following values in it:
Updated=true Version=201412270
(it's possible you may need to increment the Version key to some larger value before this works.)
If that doesn't work, the nuclear option is to edit the starttde script to prevent the updater from being called--comment out everything from
if [ -d "$tdehome" ]; then # Run some R14 updates.
to
# Please see tdestartupconfig source for usage.
to do that.
Hope that helps.
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
Leslie Turriff composed on 2018-04-25 22:03 (UTC-0500):
Yes! This worked for both accounts. Thank you very much.
That's a workaround, not a fix. A correct fix that won't cause trouble down the road, if not already, surely requires existence and use of ~/.trinity.
On 2018-04-25 22:29:12 Felix Miata wrote:
Leslie Turriff composed on 2018-04-25 22:03 (UTC-0500):
Yes! This worked for both accounts. Thank you very much.
That's a workaround, not a fix. A correct fix that won't cause trouble down the road, if not already, surely requires existence and use of ~/.trinity.
True, but I've not seen anything that works differently in this account, except for the irritating messages at login. Once I'm past them, the account works exactly as it always did.
-
E. Liddell -
Felix Miata -
Leslie Turriff