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_RUNTIME_DIR is usually set by your desktop environment. If you don't have it add it to your X startup file, or something.
I use the MATE desktop. Checking the environment in Slackware indicates the variable is not set. Likewise for Xfce.
Unlike other XDG_* variables, XDG_RUNTIME_DIR does not have a default location.
Quote:
It should not be set in profile.d.
As there is no default location defined for the XDG_RUNTIME_DIR variable, a common location is needed so all users get the variable set the same. /etc/profile.d is a legitimate location for such environment variables.
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user'
From where is this log string pulled? Is this a KDE/Qt thing? With MATE and Xfce there is no such variable and there is no /tmp/run-time-user.
This proposal might require PAM. I ran a quick test. On other distros /run/user is chmod 755, chown root:root. The user does not have permissions to create /run/user/$UID. Something else is required to create that directory with the correct permissions and ownership.
In Slint this goes in ~/.profile when a user is created as it is in /etc/skel/.profile, but yes it would be better to put that in a file in /etc/profile.d so it be at the system level thus can be modified by each user or for all of them.
The reason I prefer to have the same directory for XDG_RUNTIME_DIR and XDG_CACHE_HOME is that can help software that need a socket provided by another software to find it.
PS This proposal of course doesn't require PAM.
Last edited by Didier Spaier; 06-24-2018 at 03:29 PM.
Qt5 programs write it there, according to xsession log.
Okay, thanks. Apparently not all other desktop environments look for or set that variable.
Quote:
PS This proposal of course doesn't require PAM.
To clarify, I was not proposing PAM. Only commenting that my original proposal might not succeed without PAM.
Quote:
In Slint this goes in ~/.profile when a user is created as it is in /etc/skel/.profile, but yes it would be better to put that in a file in /etc/profile.d so it be at the system level thus can be modified by each user or for all of them.
Yes, I understand this works when configured at each individual user. The other distros do something different because /run/user/$UID is created for each user without user-based configs. Hence, my after thought that perhaps the trickery is performed by PAM. Or by that init system that gets most users in this forum frothing at the mouth.
I appreciate your feedback Didier. I think you have hit upon a useful idea. And I like the idea that PID files, sockets, etc. are all in tmpfs.
Edit: Regarding permissions, if /run/user is 777 then each user can create /run/user/$UID and export XDG_RUNTIME_DIR respectively. The distinction is on other distros where /run/user is 755 root:root and each $UID subdirectory is 700 $USER:$USER. I chose /run/user because that is the norm on all other users. Perhaps though, if Qt/KDE is defaulting to /tmp/runtime-$USER, my proposal would work just fine there. I will run a proof-of-concept test.
I have been using /var/run sym-linked to /run for a couple of years or more. While possible, I have not encountered such issues. On my Slackware systems, everything is repopulated with each boot. Unlike /var/tmp, I don't believe /var/run is intended to be a persistent storage location. Additionally, rc.S scrubs /var/run: rm -f /var/run/* /var/run/*/* /var/run/*/*/*.
This only removes files in /var/run/ and below, not the subdirectories. These directories are created from slackware-current packages alone:
Are they all automatically recreated with correct permissions if they don't exist? (If yes, then maybe they should be removed from the packages? ) Surely some Slackbuild packages will create some more.
While the idea to symlink /var/run to /run is probably good, i still fear that some packages will need adjustments to handle it.
Last edited by Markus Wiesner; 06-24-2018 at 04:55 PM.
Qt5 programs write it there, according to xsession log.
I notice qt5 is not part of the stock Slackware, including Current. With qt4.*, this message does not appear in the xsession log and no /tmp/runtime-$USER directory is created. So thus far, Slackware has no common way to set $XDG_RUNTIME_DIR.
This raises another Current feature request. Slackware does not have a way to create a $HOME/.xsession-errors log. I have used my own /etc/xprofile to create the log and I modify the xinitrc files to source /etc/xprofile.
Pat, could we please find a way to automatically create $HOME/.xsession-errors?
Are they all automatically recreated with correct permissions if they don't exist?
I can answer only from my own n=1 experience, but yes, all subdirectories are recreated on boot.
I do not recall how I modified my Slackware systems to use /var/run. I think all I did was boot or drop to init 1, delete all /var/run files and directories, and then manually created the sym link.
As I mentioned previously, for those who do not like the idea, a simple /etc/default/var_run would allow users to define the behavior they prefer.
rc.S would need to be modified to clean the disk of hard-coded subdirectories after the user configures /var/run to tmpfs and reboots. Something like:
Code:
if [ -r /etc/default/var_run ]; then
if [ "$VAR_RUN_IN_TMPFS" = "true" ]; then
# User wants /var/run in tmpfs.
if [ -d /var/run ] && [ "`readlink /var/run`" = "" ]; then
# Not a sym link but should be.
rm -rf /var/run
ln -s /run /var/run
else
# /var/run does not exist
ln -s /run /var/run
fi
else
# User does not want /var/run in tmpfs.
rm -f /var/run/* /var/run/*/* /var/run/*/*/*
fi
else
# User does not want /var/run in tmpfs.
rm -f /var/run/* /var/run/*/* /var/run/*/*/*
fi
rm -f /etc/nologin \
/etc/dhcpc/*.pid /etc/forcefsck /etc/fastboot \
...
Quote:
i still fear that some packages will need adjustments to handle it.
I don't think /var/run is supposed to be a persistent directory across reboots. Thus, all processes using /var/run should already be well designed to populate /var/run as needed. And this has been my observation for my use case.
Slackware does not have a way to create a $HOME/.xsession-errors log. I have used my own /etc/xprofile to create the log and I modify the xinitrc files to source /etc/xprofile.
I'm bored too, but not bored enough to try and re-invent the wheel..
In a stock Slackware, XDG_CACHE_HOME also is not defined. According to the XDG Base Directory Specification, compliant apps are supposed to default to ~/.cache when not defined.
Although obviously apps are working without the defined environment variables and using the variables offers no noticeable performance difference, using the variables does nicely consolidate temporary files into one location. Without the environment variables the temporary files are stored in three different locations.
If /tmp is mounted using tmpfs, this provides a cleaner way of ensuring various PID and socket files are deleted on reboot.
Defining $XDG_CACHE_HOME to a tmpfs location might work for some users but likely not for all. For example, some users might want to retain their browser cache across reboots without explicitly defining a cache directory in their browser profile.
This one must only exist when starting named with -u otheruser because it first drops privileges and then can't create the directory in /var/run/ because of insufficient permissions. So only a problem if someone (like me ) changed the default.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.