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:
containing 00 (2 times 0).

@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

You've convinced me. I'm okay with ~/.cache.

Wait, I take it back. Now I hate it! ;)

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.

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...

No i have this since longtime.

In my case, this stray /.cache folder appeared after the last updates in slackware-current.

I don't have this problem.

What are you running on boot?

Robby, it's due to rc.networkmanager, when is inactived the .config isn't created at boot ;)

I think it starts too early in the init, because when you start it under x, there is no problem

By placing "echo -n "XXX: " ; ls -a /" statements in /etc/rc.{S,M} and drilling down I found that the /.cache file is created by the /usr/sbin/NetworkManager invocation done in /etc/rc.d/rc.networkmanager:
As /usr/sbin/NetworkManager is an "ELF 64-bit executable" my journey ends there.
:D

Nice catch!
On my desktop, where I do not use NetworkManager, I do not see a /.cache directory. On my laptop, where I do use NetworkManager, I do see a /.cache directory.

Yes, after installing wicd the /.cache directory is no longer created.
:D

That is interesting, but it doesn't happen here...
I also don't see anywhere in NM source that uses any .cache directory :/

Humor me on this. Before the NM invocation stanza, add a "sleep 2" and then your echo/ls line and see what happens. I think it might be bluez doing it but it just takes a bit of time and NM gets started before that cache dir is created...

I think bluez is a false trail. The laptop where I observe the problem does not have /etc/rc.d/rc.bluetooth executable.
I added a call in /etc/rc.d/rc.S just before the stanza to configure ISA Plug and Play devices to a script to watch for the creation of a directory in /
The resulting output seems to confirm NetworkManager as the culprit.

Yes, i have one other install of current with openrc, and this install, doesn't have this cosmetic problem.

Hmmm ... an interesting, if harmless issue here ...

I've done this to myself from time to time by referencing an unitialized or a misspelled Directory Variable in a /bin/sh script.

Example:
Since I don't run many scripts as root, and because a joe user cannot create a Directory in the fs root, the above code fails if I bother to check RetCodes

OTOH, if I run such code as root, I end up with an unintended directory in the fs root.

Just sayin' :)

Anyhow, like burdi01, I found no references to a .cache directory in any Current NetworkManager files and I am running wicd so I have no /.cache directory on my systems.

But NetworkManager requires dbus (:) another Project with the LoveBucket name on it :)) and I do have a $HOME/.cache/dbus/ directory.

I've not scanned the dbus code but I wonder if the XDG_DATA_HOME variable that 55020 found affects the location of the .cache/dbus/ directory ?

But then, how would one set XDG_DATA_HOME during boot ???

-- kjh

@rworkman: That would be in contradiction with my finding that when using wicd (which precludes NM) the /.cache directory is not created.
Also, just as allend, I do not have bluez enabled (actually it is not even installed).

Anyway, I did as requested (and with an even longer sleep):
The .cache directory first pops up with the "M2cD" display.
:D

This is working for me to stop the creation of /.cache directory.
From https://standards.freedesktop.org/ba...ec-latest.html

Well, here's the feedback from thaller in #networkmanager:
Anybody feel up to that? :-)

I've made an inquiry of mclasen, the guy who does glib releases; let's wait and see what he says before any significant time is invested in debugging...

In the meantime, something like this near the top of rc.networkmanager should move the problem somewhere other than /:

Crap, I just saw this. Yes, this is a nice workaround and essentially what I reposted.

Confirmed to resolve (work around?) the issue for me too.
:D :D :D

Grr - This issue is back in -current with the latest NetworkManager-1.8.0 which silently overwrote my existing /etc/rc.d/rc.networkmanager on upgrade.

I don't see how it overwrote your rc.networkmanager :/

The problem is in this function of the doinst.sh
The old file is copied, then immediately overwritten.
Perhaps

preserve_perms() usually has a config $NEW rather than a mv $NEW $OLD where files are to be treated as config files and left for the user to manage. It would probably be more in keeping with the slackware way of doing things to do that than creating a *.orig in this case.

The .cache folder is using by some apps or services.

In my $HOME/.cache i have some folders like gstreamer-1.0 , obexd , google-crome , and others.

Is not an error ,some apps, want this ,if no exists "create a new one".

Thats all.

This thread is about /.cache, not ~/.cache as reminded by the OP is post #10

PS The XDG Base Directory Specification states:But no user should have / as $HOME

@burdi01:from the ChangeLog for Slackware-Current:Thus I assume that this thread could be marked as [SOLVED]

PS This complies to the XDG Base Specification as reminded by my previous post. Sounds logical as our friend LP is both NM's author and a co-author of the spec :D(1)

PPS I just checked: when /etc/rc/d.rc.M starts rc.networkmanager, $HOME is set to "/". I have no idea on why nor what sets it, but that sounds weird as POSIX states:But as nobody is logged in when rc.M starts rc.networkmanager, why is HOME already set?

Anyway as rc.M runs on behalf of root, setting XDG_CACHE_HOME as /root/.cache in rc.networkmanager is indeed the right thing to do.

EDIT (1) No LP is not author of NM, sorry for this mistake. As we say here on ne prête qu'aux riches.

I still cannot help feeling that this solution is working around the problem rather that resolving the cause.
Anyway, marking this thread as solved.
Thks everyone.
:D

Edit: Hmm, when reading back this post I notice that it sounds more negative than I meant it to be.

Yes, it does feel kind of ugly, but then, that's NetworkManager for you.

Well NM just does what's written in the aforementioned spec. How is that wrong or ugly?

The alternative would be that if HOME is set to / NM sets it to /root. I wouldn't like that at all, as it would be too much intrusive: it's simply not NM's job to set HOME. Doing that in the startup script instead is way better, as the admin can easily change this setting if so inclined.

Previous content deleted: I mistakenly quoted my post #41 instead of editing it, sorry.

XDG is a user centric desktop spec. NM is clearly designed to be a component of a desktop but it's being run here in the role of a system-wide network interface management daemon. XDG should have no role in the operation of system daemons, in the UI control applets run by their users certainly, but not the backend daemons themselves.

It's much the same issue as pulseaudio, which also fails to respect the separation between user desktop component and system-daemon. IMO it's just architecturally flawed design and a very non UNIXish way of going about things.

If a daemon needs to store state, cache files etc, then there are locations in the /var hierarchy designed to cater to that need.

I think the twist is that at this point (while running boot scripts) root hasn't actually logged in - at least not in the way that anyone logs in as root once the system is up & running. Therefore that instance of root that's running the boot scripts hasn't (I presume) sourced /etc/profile etc., to obtain a normal environment. In this case, it's sort of understandable that root's "home" is /. What should it be without having been allocated a home directory elsewhere? At least / is guaranteed to be there.

Consider also the case of an ordinary user whose allocated home directory is not available at login time for some reason (unavailable nfs mounted home directory springs to mind); in that case the use is logged into /. To my mind, this is just like root at boot time with no home directory set.

chris

Just wondering what would happen in case HOME be not set at all then. Maybe I'll unset it early in the startup sequence just to see what happens. In a VM, not to break my real systems.

Just, for info, i have one other install of slack-current on other partition, with openrc, doesn't /.cache appears, it seem the networkmanager service in open rc service start with timeout, But I do not know if this is the problem.

As the discussion in this thread shows, NetworkManager (NM for short) expects XDG_CACHE_HOME to be set. As NM is started at boot (in rc.M) this implies that it expects this "user" setting to be set when no user is logged in yet.
For as far as I am aware NM is developed and tested on the systemd side of the house. Maybe systemd sets those "user" settings at boot, reasoning that as root is the owner of the system he is the implicit user at boot. If that is the case chances are that more applications will now or in the future tacitly assume the "user" settings to be set at boot.
To prevent future "surprises" it might be cautious to set those XDG "user" settings and/or e.g. $HOME as for root at boot (in rc.M or even in rc.S).

I know I am "cursing in the church", please do not shoot me.
:D