Current64: Where does the /.cache file come from?
Current64: After each boot, before starting X I already have an empty /.cache file, for which I cannot find "who" creates it.
Taking the risk to sound stupid, but is there anyone who knows? :D |
It doesn't occur on my frankenstein 14.1 install or my normal 14.2 install. I don't have any -current installs to test. However, my first guess is this is a culprit of 3rd-party software you have installed. Maybe an rc.d script that is missing a variable being set?
First thing I'd try is to run fgrep ".cache" /etc/rc.d/* to see if it can find any files containing .cache in them (fgrep prevents regex from being used, so it interprets the . as a literal period, not as a wildcard like in normal regex... I can never remember how to properly escape it for a regular grep). It might also be worth checking any 3rd-party programs you have starting up automatically. If the file isn't being created directly by a script in /etc/rc.d/, it could be by one of the scripts called by one of those rc.d scripts (like rc.program calls /usr/bin/program, which may also be a shell script). If you don't want to do all that searching, you could try disabling all your 3rd-party items in /etc/rc.d/ (don't forget stuff in rc.local) and see if the file is still created when you reboot. Don't forget to remove the .cache before you restart! |
Are you logging in to X as root? KDE Plasma might be creating those dirs for root, and dumping them, incorrectly, in /.
I did two minutes (OK, maybe it was more like 90 seconds) of testing and it appears that this happens on Fedora 25 (I'm at work right now, so that's the machine I have handy). |
I did scan the /etc directory for ".cache" (and even for "cache") and followed the boot sequence up to and including logging in - I boot into lvl3, so no X. As I could not find a "culprit" I posted my question.
Today I repeated this procedure, and again to no avail... I took the way of the least resistance and delete the /.cache directory in my /etc/rc.d/rc.local. Thank you for responding. :D |
looks like it was created during installation (at least on ubuntu) and also there is a file inside:
Code:
/.cache/dconf/user |
@pan64: I delete that directory, but every time after a reboot it is back ...
As an aside, it is not present on my Xubuntu installation. :D |
looks like it is created by apparmor
|
*Lots* of software creates and uses subdirectories of ~/.cache -- it tends to be packages that also use .local and .config. If you're cool with .local and .config (and you probably are, unless you don't want software to remember your config from one login to the next) then you should also be cool with .cache. Life's too short to stop software trying to speed itself with a bit of cacheing.
It's another fdo idea by the way (https://standards.freedesktop.org/ba...ec-latest.html), and yes, that's our friend Mr Lovebucket on the authors list. From the spec, you can try to specify an alternative name with XDG_CACHE_HOME if it really bothers you. Edit: here's a totally random list of totally random stuff that uses it: calibre darktable dconf fontconfig fontforge g-ir-scanner geeqie gegl-0.2 google-chrome gpg-agent-info gstreamer-1.0 guile gvfs-burn inkscape instantfpc keybase keyring-* matplotlib mc moonchild productions mozilla osmgpsmap pip sessions spotify thumbnails thunderbird vlc webkit xfce4 |
Quote:
Quote:
|
Note to everyone: I am talking about an empty /.cache directory, not one like ~/.cache !
:D |
ooooooo!!! sorry burdi01, I've made myself look stupid again :D
As you say it definitely shouldn't be there (of all places). Thanks for the report! If you can identify its creation time to the nearest second, hopefully that'll narrow down what did it. And then we can smite the damn thing. |
Have you tried stopping any of your custom rc.d entries? That would mean making rc.d and any non-official rc.d script non-executable. If it still occurs, then it would likely be something in -current itself and not any of your 3rd-party software. But I can't think of any official Slackware packages that would create that directory during the boot process, so I'm expecting it is a 3rd-party software that doesn't have its variables set up properly.
The following command will list all executable files in /etc/rc.d/, if you also include your contents of rc.local, it might help us narrow down your possible culprits. Code:
find /etc/rc.d/ -maxdepth 1 -perm -111 -type f |
I'd lean toward finding out what's running as root (or at least starting as root and maybe dropping privs), then see if any of them have a $HOME directory that is either / or unset (which might cause them to default to /).
|
this .cache is recreated after reboot or at boot.
|
That nasty folder on / appeared after the latest font adventures...
|
All times are GMT -5. The time now is 09:25 PM. |