[SOLVED] Current64: Where does the /.cache file come from?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
Last edited by GazL; 05-27-2017 at 06:02 AM.
Reason: speeling ;)
...
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:
Code:
HOME
The system shall initialize this variable at the time of login to be a pathname of the user's home directory. See <pwd.h>.
But as nobody is logged in when rc.M starts rc.networkmanager, why is HOME already set?
...
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
Last edited by chris.willing; 05-27-2017 at 05:29 AM.
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.
While I agree with your analysis burdi01, such assumptions during boot sound Scary and Dangerous to me.
I wonder what are the chances of the new generation of ex-Windows programmers, now doing Linux Code, learning that Linux is not Windows and that my Servers are not your LapTop, etc, etc, etc ...
Or if you don’t want to use some of the more modern components like Networkd, then use something else. I mean, on my laptop I even use NetworkManager, because Networkd doesn’t do wireless, right? Networkd is more for containers and servers. So if you want to adopt Systemd, you can absolutely adopt the baseline, which is the three components that I mentioned. You can keep the rest of the system – however, our implementation of the individual parts is usually pretty convincing, and usually people then replace more.
The current version of NetworkManager offers the NetworkManager-wait-online.service which gets pulled in by network-online.target and thus by your service. This special service ensures that your service will wait until all connections configured to be started automatically succeed, fail, or time out.
The current version of systemd-networkd blocks your service until all devices are configured as requested. It is easier in that it currently only supports configurations that are applied at boot time (more specifically the startup time of `systemd-networkd.service).
See also this page to know how that's handled with systemd.
Bottom line: Of course Fedora and Slackware handle starting NetworkManager in different fashions, but that is basically the same application, I assume.
Last edited by Didier Spaier; 05-27-2017 at 10:06 AM.
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.
Well HOME is set to / as soon as the system starts. Having seen that HOME is already set to / at the beginning of /etc/rc.d/rc.S, at first I thought that it was done by some userland program, like bash or login. But eventually I saw this line in the kernel source (file init/main.c):
So when the system is initialized HOME is set to /.
A see a similar thing in kernel/reboot.c
Code:
static int run_cmd(const char *cmd)
{
char **argv;
static char *envp[] = {
"HOME=/",
"PATH=/sbin:/bin:/usr/sbin:/usr/bin",
NULL
};
int ret;
argv = argv_split(GFP_KERNEL, cmd, NULL);
if (argv) {
ret = call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
argv_free(argv);
} else {
ret = -ENOMEM;
}
return ret;
}
This function is executed before rebooting or shutting down the system.
What puzzles me is that if I unset HOME at the beginning of rc.S (which has no immediate obvious nasty consequence, by the way), when rc.M starts HOME is again set as /. Any idea why, anyone?
PS Maybe this is something similar to any variable setting in the command line automatically "exported" system wide?
Last edited by Didier Spaier; 06-01-2017 at 06:27 PM.
Reason: PS added
What puzzles me is that if I unset HOME at the beginning of rc.S (which has no immediate obvious nasty consequence, by the way), when rc.M starts HOME is again set as /. Any idea why, anyone?
PS Maybe this is something similar to any variable setting in the command line automatically "exported" system wide?
Within rc.S all you can do is unset or change the value of $HOME within the scope of rc.S. It's already been defined at a higher shell level, so that's where rc.M gets the value from. Similarly, any other variable you define within rc.S will only be available there (or, if exported, there and in any subshells of rc.S). Set something like BOGUS_VARIABLE=foo in rc.S (and export it) and then try to echo it in rc.M and it won't be set, because rc.M is not a subshell of rc.S.
Within rc.S all you can do is unset or change the value of $HOME within the scope of rc.S. It's already been defined at a higher shell level, so that's where rc.M gets the value from. Similarly, any other variable you define within rc.S will only be available there (or, if exported, there and in any subshells of rc.S). Set something like BOGUS_VARIABLE=foo in rc.S (and export it) and then try to echo it in rc.M and it won't be set, because rc.M is not a subshell of rc.S.
That makes sense, thanks for the clear explanation.
Last edited by Didier Spaier; 06-01-2017 at 10:40 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.