I have posted two threads re: “dbus session manager not starting, connection refused” afterproblems that occurred after a routine zypper patch, and updates, including some nvidia updates from their repo.
I did a reinstallof root / while retaining /home. With a newly created username (uid 1001), I can now login to gnome and mate fine. My original user (uid 1000) during login, however, still gets the same message saying “could nor connect to session bus, could not connect to socket /tmp/…, connection refused” and upon close gives " could not acquire name on session bus". My original user can login to icewm desktop successfully.
There surely must be a way to diagnose and repair the login capabilities of my old user now that I have access to all system capabilities.
I do have same password for both users. I hope that is not a problem. Both users (1000 and 1001) are in both users and adm group.
I wish to recover use of my original home directory without transferring all the stuff in there manually.
I need some ideas for repair to original user login capabilities.
Therefore, there’s an issue with the configuration files of the desktop(s) which are causing these problems.
The diagnosis is to review all of the problem user’s configuration files – as a KDE-only user, I can only say that, for KDE Plasma 5 the user’s configuration files are located in '~/.config/ – I have absolutely no idea where other desktops store the user’s configuration files – the desktop’s documentation could possibly help here.
The usual repair method for any given user is, to delete all that user’s desktop’s configuration files either, from another user’s GUI desktop session or, from a Linux VT session – <Ctrl-Alt-F1> through <Ctrl-Alt-F6> – usually . . .
For conventional UNIX® and Linux there’s no relationship between user’s passwords and, the “adm” group (used for system monitoring tasks) also shouldn’t be an issue.
Unfortunately, there’s no easy way to perform this task.
Be aware that, only the user’s “working” (visible) file set should be moved back to the newly created “clean” user’s home directory.
If, you were to also move the “hidden” directory content to the “fresh, clean” home directory then, the new “clean, fresh, working” desktop configuration will be overwritten by the “old, bad, non-functional” desktop configuration.
I have ongoing problems with dbus session manager not recognizing my USERNAMES and inability to login to desktops except icewm. I am on my third added username. I had almost finished moving all the processes from my first username to my new second username account and home directory. I installed python anaconda into the local user home directory as one of the last steps. Subsequently now my second user name generates the same dbus session error messages that my first username did and will not login to any desktops except icewm. I did install anaconda in my first username prior to that becoming unusable in the same manner.
In looking further through the Forum files, I found a dbus session manager problem thread that was associated with the installation of anaconda python. The thread is: Boot issue: Could not start D-Bus. Can you call qdbus-qt5?started by elpurpole, 19-Oct-2017 13:06. This thread refers to another user that had dbus session issues after anaconda install.
I am thinking that my dbus login issue is related to the install of anaconda into a user account. I don’t know what could be getting corrupted by anaconda install.
I would like to know if others using LEAP 42.3 have successfully installed anaconda into a user account and still been able to login to mate or gnome desktops without dbus session issues.
I would also really like to get some detailed steps on how to correct the problems within my last two old username home directories and their .config files. There are session related files in there but I have no idea what they do.
I found other instances of anaconda messing with dbus processes. From these, I found a solution to dbus session manager not logging into my usernames was indeed caused by the addition of anaconda python process. I found that anaconda adds a line in .bashrc related to export of the anaconda bin path. I commented out that line in each of the .bashrc files for my previous two usernames and they now boot into mate and gnome as before.
Of course, I now don’t have anaconda access but I do have my very customized desktops and installed processes back.
Next to figure out how to install anaconda in another manner. Perhaps into root.