You are not logged in.
I completely removed all packages related to kde and plasma and switched to i3 . But my /home/user/.config has a list of residual configuration files from kde and plasma. I removed that user with its home directory and created a new user . All those residual packages re-appeared magically in my current user once again .
Here is list of those config files haunting my system
https://wtools.io/paste-code/b238
How do I get rid of these ghost kde/plasma files permanently?
Thanks
Offline
pacman -Qs kde
pacman -Qs plasma
systemctl status #Look for kded and plasma processes
? This plain reads like quite a few plasma daemons are still around.
Last edited by V1del (2020-11-11 15:42:19)
Offline
pacman -Qs kde pacman -Qs plasma systemctl --status #Look for kded and plasma processes
? This plain reads like quite a few plasma daemons are still around.
I already checked this
# pacman -Qs kde
local/libappindicator-gtk3 12.10.0.r296-1
Allow applications to extend a menu via Ayatana indicators in Unity, KDE
or Systray (GTK+ 3 library)
local/libblockdev 2.24-1
A library for manipulating block devices
pacman -Qs plasma
No output
systemctl list-unit-files
Offline
Post output from 'systemctl status'. For example, sddm doesn't depend on KDE or plasma, so it wouldn't show on either pacman -Qs kde/plasma.
Offline
Post output from 'systemctl status'. For example, sddm doesn't depend on KDE or plasma, so it wouldn't show on either pacman -Qs kde/plasma.
@twelveeighty
here is the output
Offline
Did you look at it yourself? There's clearly sddm references in there. Find out if/how sddm can spawn KDE daemons on login? Also run the same command, but with --user specified. You may find that kactivitymanagerd and kglobalaccel5 are running via dbus activation. Again, I would look at sddm and see if you can tell it not spawn any KDE daemons.
Offline
Did you look at it yourself? There's clearly sddm references in there. Find out if/how sddm can spawn KDE daemons on login? Also run the same command, but with --user specified. You may find that kactivitymanagerd and kglobalaccel5 are running via dbus activation. Again, I would look at sddm and see if you can tell it not spawn any KDE daemons.
Here it is as --user specific
https://wtools.io/paste-code/b23X
I have a big fan of sddm but seeing how it spawns kde daemons I might shift to lightdm though I never liked it
Offline
SDDM has no inherent relation to KDE and should not be capable nor the culprit for the issue in this particular instance.
From that aspect that output looks okayish. Maybe post a journal of a relevant boot process, or probably more useful to get at a direct culprit employ the audit framework: https://wiki.archlinux.org/index.php/Audit_framework
Also were those files instantly on the new user or just after logging in? What does your /etc/skel look like?
Last edited by V1del (2020-11-11 20:55:43)
Offline
Also were those files instantly on the new user or just after logging in? What does your /etc/skel look like?
Immediately a new user was created and immediately on an another user I created to check if that gets these files or not as well
My /etc/skel is identical to my /home/.config loaded with all these ghost files
Offline
Then that's your problem... why do you have these in your /etc/skel ? No KDE software nor package populates this by default. /etc/skel is used as the skeleton home dir for new users.
Last edited by V1del (2020-11-11 21:17:29)
Offline
Then that's your problem... why do you have these in your /etc/skel ? No KDE software nor package populates this by default. /etc/skel is used as the skeleton home dir for new users.
I don't know why they are still residing in /etc/skel when I have got ridden of kde long time ago . This is a decade old arch linux installation still living and working so loads of clutter from a decade is lying around all over the places.
I am reading about how to clean /etc/skel , but just wondering if I remove all these and other unwanted packages from /etc/skel will this issue be resolved? Or will they come back in /etc/skel automatically again too? How safe it is to wipe /etc/skel carefully ?
Offline
Not many things places garbage in there, you can delete anything not owned by anyone with a check of “pacman -Qo” without side effects, of course, leaving anything you made and want there.
Last edited by GaKu999 (2020-11-12 05:05:48)
Offline
As mentioned, no pacman package (... other than bash and maybe other shells for default bashrc and profile files) nor KDE program I've seen (... over the last decade) writes there. This must've been something you did at some point.
Offline
V1del wrote:Then that's your problem... why do you have these in your /etc/skel ? No KDE software nor package populates this by default. /etc/skel is used as the skeleton home dir for new users.
I don't know why they are still residing in /etc/skel when I have got ridden of kde long time ago . This is a decade old arch linux installation still living and working so loads of clutter from a decade is lying around all over the places.
I am reading about how to clean /etc/skel , but just wondering if I remove all these and other unwanted packages from /etc/skel will this issue be resolved? Or will they come back in /etc/skel automatically again too? How safe it is to wipe /etc/skel carefully ?
I'm a very long-time user of KDE and I only have three .bash* files in my /etc/skel (.bash_logout, .bash_profile and .bashrc). All of the .bash* files look very generic, nothing like the same files in ~/. I would guess that you could archive /etc/skel, or rename it, and start over.
Offline