Requests for -current (14.2-->15.0)

Didier Spaier · 06-24-2018, 02:33 PM

For some packages it could be helpful to provide the configuration summary included in the configure log (in case there is one, of course).

This can help user wanting to tune the build to add or remove features, when allowed by the software.

This would go in the source directory alongside the SlackBuild.

Two examples are attached: one using the SlackBuild for libewp in Slackware-current another one for mlterm (SlackBuild from SBo heavily modified).

Maybe something similar can be provided for cmake.

upnort · 06-24-2018, 02:43 PM

Quote:

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.

elcore · 06-24-2018, 02:53 PM

Quote:

Originally Posted by upnort

As there is no default location defined....

It does have a default. Is there a reason to insist on changing the default?

Code:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user'

upnort · 06-24-2018, 03:02 PM

Quote:

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.

elcore · 06-24-2018, 03:18 PM

Quote:

Originally Posted by upnort

From where is this log string pulled?

Qt5 programs write it there, according to xsession log.

And my user is called 'user' (to be precise it's '/tmp/runtime-your_current_username')

Quote:

Originally Posted by upnort

This proposal might require PAM.

I see. Maybe use a distro with PAM, or ivandi's template which includes PAM.

Didier Spaier · 06-24-2018, 03:25 PM

I consider the XDG Base Directory Specification as the reference for such environment variables.

I never had (or heard of ) an issue with these settings which comply with the aforementioned specification:

Code:

 
export XDG_CACHE_HOME=/dev/shm/$(whoami)
mkdir -p /dev/shm/$(whoami)
chmod 700 /dev/shm/$(whoami)
export XDG_RUNTIME_DIR=$XDG_CACHE_HOME

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.

upnort · 06-24-2018, 03:45 PM

Quote:

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.

Markus Wiesner · 06-24-2018, 04:46 PM

Quote:

Originally Posted by upnort

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:

Code:

drwxr-xr-x root/root         0 2018-05-01 10:22 var/run/dbus/
drwxr-xr-x root/root         0 2018-06-09 11:42 var/run/cups/
dr-x--x--x lp/sys            0 2018-06-09 11:42 var/run/cups/certs/
drwxr-xr-x mysql/mysql       0 2018-06-02 16:33 var/run/mysql/
drwxr-xr-x root/root         0 2018-04-13 09:13 var/run/ConsoleKit/
drwxr-xr-x root/root         0 2018-06-12 16:35 var/run/nscd/
drwxr-xr-x root/root         0 2018-05-11 18:45 var/run/named/
drwxr-xr-x root/root         0 2018-04-13 10:38 var/run/iptraf-ng/
drwxr-xr-x rpc/root          0 2018-04-13 10:53 var/run/rpcbind/
drwxr-xr-x root/root         0 2018-05-29 12:31 var/run/stunnel/
drwxr-xr-x root/root         0 2018-05-17 12:29 var/run/samba/

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.

upnort · 06-24-2018, 05:01 PM

Quote:

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?

upnort · 06-24-2018, 05:25 PM

Quote:

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.

elcore · 06-24-2018, 06:18 PM

Quote:

Originally Posted by upnort

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

These features are so old they have beard.

Code:

grep .xprofile /etc/X11/xdm/Xsession
grep .xsession-errors /etc/X11/xdm/Xsession

I'm going to go chill now, good luck.

upnort · 06-24-2018, 06:18 PM

I created /etc/profile.d/xdg.sh:

Code:

if [ ! -d /tmp/runtime-$USER ]; then
  mkdir -p /tmp/runtime-$USER
fi
if [ -d /tmp/runtime-$USER ]; then
  export XDG_RUNTIME_DIR=/tmp/runtime-$USER
fi

When I started X the /tmp/runtime-$USER directory was populated with the following directories:

dconf
gvfs
keyring
pulse

Normally, because XDG_RUNTIME_DIR is not defined in Slackware, the same directories are created elsewhere:

dconf -> ~/.cache/dconf
gvfs -> ~/.gvfs
keyring -> ~/.cache/keyring-$uuid
pulse -> /tmp/pulse-$uuid

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.

I hope this information helps!

upnort · 06-24-2018, 06:21 PM

Quote:

grep .xprofile /etc/X11/xdm/Xsession
grep .xsession-errors /etc/X11/xdm/Xsession

Yes, quite nice for people who use xdm. Does this help when using other login managers?

Markus Wiesner · 06-25-2018, 01:23 AM

Quote:

Originally Posted by upnort

I can answer only from my own n=1 experience, but yes, all subdirectories are recreated on boot.

I took some minutes to test it:

Code:

drwxr-xr-x root/root         0 2018-05-01 10:22 var/run/dbus/
drwxr-xr-x root/root         0 2018-06-09 11:42 var/run/cups/
dr-x--x--x lp/sys            0 2018-06-09 11:42 var/run/cups/certs/
drwxr-xr-x mysql/mysql       0 2018-06-02 16:33 var/run/mysql/
drwxr-xr-x root/root         0 2018-04-13 09:13 var/run/ConsoleKit/
drwxr-xr-x rpc/root          0 2018-04-13 10:53 var/run/rpcbind/

These are all recreated automatically after being removed.

Code:

drwxr-xr-x root/root         0 2018-05-17 12:29 var/run/samba/

This one must exist before starting smbd/nmbd, but that's already handled by rc.samba.

Code:

drwxr-xr-x root/root         0 2018-05-11 18:45 var/run/named/

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.

Code:

drwxr-xr-x root/root         0 2018-04-13 10:38 var/run/iptraf-ng/
drwxr-xr-x root/root         0 2018-05-29 12:31 var/run/stunnel/

These seem to be unused? Both programs write their pid file directly into /var/run/.

Code:

drwxr-xr-x root/root         0 2018-06-12 16:35 var/run/nscd/

How is /usr/sbin/nscd supposed to be started? Never used it … but when trying to start it directly this one failed if /var/run/nscd/ does not exist.

So sorry for the noise and one more vote from me to symlink /var/run to /run (and then removing above directories from the packages)

chrisretusn · 06-25-2018, 07:35 AM

Interesting discussion that probably should have it's own thread.