Description of problem: A .config and a .bash_history file are created in the / dir when X is started ( or attempted to start ). Version-Release number of selected component (if applicable): How reproducible: Login or attempt to start X remotely. Steps to Reproduce: 1.ssh into a machine. 2.startx 3.ls -a / The startx will fail, but the files are created. If the files are removed. They will be created at any X login, failed or or not. This is for any user not root. There are several reports on alt.os.linux.mageia about this.
Please ignore the reference to .bash_history. That is/was a different problem.
The .bash_history in the root directory gets created anytime you start in run level 1. The .config directory did exist in my Mageia 1 clean install, however, once I delete it, it does not get recreated on my system. Same with my Mageia Cauldron installation.
CC: (none) => davidwhodgins
so, do we know where this .config comes from ? I have it on my system too but never SSHed to the machine.
CC: (none) => stormi
Keywords: (none) => NEEDINFO
I ran quite a few tests, each time starting with a minimal+lxde install, using run level 3. Installing task-kde4-minimal from a lxde-terminal /.config/trolltech.conf was created (based on the timestamp and /var/log/syslog entries) during the processing of the file-triggers from kdebase4-workspace. The dbus configuration was reloaded 4 times as kdebase4-workspace was installed. Based on the time and ps output, the file was created the same second a kwin task was started (only process started that second still running when I checked the ps output). But, during 6 repeat installs under various conditions, including one just like the above, it was never recreated. System was restored from image each time I repeated the test, so I no longer have anything from the one time it was created. I'm using a single core processor, so this makes a race condition less likely. Hopefully this will help narrow down the cause, and not cause a wild goose chase. :-)
And I didn't even think of looking *inside* the .config directory! It's a Trolltech.conf file too. Assigning to mikala in case he knows about this.
Assignee: bugsquad => balcaen.john
Keywords: NEEDINFO => (none)
Well i guess if there's a file trigger launching/updating a Qt related app it's normal to have the config file from Qt created since urpmi works as root. But from what i'm reading it's not related to the startx problem at all. Maybe we should check which argument are passed to ssh before starting the xserver ?
CC: (none) => balcaen.john
(In reply to comment #6) > Well i guess if there's a file trigger launching/updating a Qt related app it's > normal to have the config file from Qt created since urpmi works as root. > But from what i'm reading it's not related to the startx problem at all. > Maybe we should check which argument are passed to ssh before starting the > xserver ? Just in case you missed it, I don't think I have a ssh server on my computer but I still have this .config/Trolltech.conf file :)
This is a duplicate of #2719 or vice versa.
See Also: (none) => https://bugs.kde.org/show_bug.cgi?id=249217
hum seems like i miss again (like in #2719) the / & not /root. Making this one duplicate since the upstream bug is already available in # 2719 Thanks dicks for noticing :) *** This bug has been marked as a duplicate of bug 2719 ***
Status: NEW => RESOLVEDResolution: (none) => DUPLICATE