shell script scratchpad directory XDG_RUNTIME_DIR or TMPDIR

[Goverp]

I'm trying to write a utility script to source from shell scripts. For various reasons the script needs to write output to a temporary file. Where to put it?

IIUC the good way on linux is to create a name with "mktemp", but there are several possible directories. $XDG_RUNTIME_DIR for me points to /run/user/nnnn, which is a particularly good home as it's on tmpfs. It's set at logon for both a normal user and for root. But if instead I issue "su -" from the normal user, it isn't set! Of course, XDG_foo comes from the freedesktop.org, so it's a bit systemd, but the definition seems sound.

Various sources (the root seems to be the Open Group Base Specifications) say $TMPDIR; there's also $TMP. Neither are set for either user or root on Gentoo.

By and large, $XDG_RUNTIME_DIR seems to use /run/user and is on tmpfs. $TMPDIR uses /tmp and may or may not be on tmpfs; default is on the rootfs, so a real filesystem.

I guess I write my own function, but that ought to be unnecessary.

Any thoughts?

[pietinger]

Where to put it?

https://refspecs.linuxfoundation.org/FH ... index.html says every linux system must have a /tmp directory ...

$TMPDIR uses /tmp and may or may not be on tmpfs; default is on the rootfs, so a real filesystem.

If your question is: How to be sure my script uses a tmpfile in RAM ?

I would answer:

1. If user=root: You have to test if /tmp is allready mounted in RAM; and if not: Do it yourself (not the whole /tmp; only your /tmp/mydir)
- or -
2. If user=user: Search for mounted dirs in RAM (like /run) and use them.

[Zucca]

If you want to store the temp files on a tmpfs... yes, I'd create a function.

• Check if $XDG_RUNTIME_DIR is set. If true, then use it
• else - Check if /run/user/<UID> exists and you have access to it
  • Caveat: On some systems, if user logs out, then this directory might face a cleanup
• Write the temporary files to "${TMPDIR:-${TMP:-/tmp}}/$USER". No need to check if its a tmpfs, since if it isn't you'd still need some temporary directory to write your stuff.

EDIT: You can omit $USER, since mktemp creates files with rw permissions for the current user only.

[trilithium]

The most portable and reliable solution is probably to just stick it in /tmp. If /tmp is not tmpfs then there is likely a good reason for this, e.g. a severely memory-starved system. If you can rely on GNU coreutils being available I suggest using

Code: Select all

mktemp --tmpdir

which will use $TMPDIR if set and /tmp otherwise.

[pietinger]

[...] If /tmp is not tmpfs then there is likely a good reason for this, e.g. a severely memory-starved system. [...]

I fully agree with only one exception: If you have security sensitive data which shouldnt be on disk.

[Goverp]

Thanks. I'll definitely have coreutils (or the rest of the script will die). I've done some tests:

It turns out that for a logged in user or root, $XDG_RUNTIME_DIR is set, and points to /run/user/<uid>.
For a user reached by "su -", $XDG_RUNTIME_DIR is unset, and the /run/user/<uid> directory may or may not exist, depending on whether the user is logged-in elsewhere.
For a user reached by "su" (no hyphen), $XDG_RUNTIME_DIR is inherited and may be unwritable! Great!
I don't have sudo installed (work of the devil), but I guess it would be at least as bad as one of the two above.

A quick bit more Googling throws up people asking how to set XDG_RUNTIME_DIR 'cos it isn't in some circumstances. I'd probably do best to assume it's another half-backed idea from the people that brought us systemd, pulse audio, and the rest of the Open Desktop crap. (The circumstance for one user was after ssh into a remote user; I tried to an Arch box I run, and it was set, but that of course is running systemd. Perhaps on sane systems, it isn't set.)

I was about to use /run/user/<uid> as follows:

Code: Select all

dir="/run/user/$(id -u)"
mkdir -p "$dir"
tempfile="$(mktemp -p $dir)"

until I found that /run/user/<uid> is a tmpfs all of its own (seems to be max 10% of memory). Presumably pam is mounting it, and therefore if the process that created it signs off while I'm using it, my tempfile would go with it.
Then I tried creating something in /run, but that's only writeable from root.

What an annoying mess. I need to think some more. Probably use /run from root, $XDG_RUNTIME_DIR if it exists, and /tmp otherwise. That still breaks if I use "su" from somewhere with $XDG_RUNTIME_DIR set, but that's probably never going to occur. Or just use /tmp like in the good old days before people started getting too clever for our own good.

[Zucca]

I think I've seen scripts checking if XDG_RUNTIME_DIR is set and then checking if the directory specified by it exists.
I think I wouldn't put anything there unless the script is meant to be run from local desktop session.

[GDH-gentoo]

It turns out that for a logged in user or root, $XDG_RUNTIME_DIR is set, and points to /run/user/<uid>.
For a user reached by "su -", $XDG_RUNTIME_DIR is unset, and the /run/user/<uid> directory may or may not exist, depending on whether the user is logged-in elsewhere.

That's by design:

$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. [...]

The lifetime of the directory MUST be bound to the user being logged in. It MUST be created when the user first logs in and if the user fully logs out the directory MUST be removed. If the user logs in more than once he should get pointed to the same directory, and it is mandatory that the directory continues to exist from his first login to his last logout on the system, and not removed in between. Files in the directory MUST not survive reboot or a full logout/login cycle.

For a user reached by "su" (no hyphen), $XDG_RUNTIME_DIR is inherited and may be unwritable! Great!

According to this, the XDG Base Directory Specification specifies "how desktops should locate files, such as config files or application data files.". Processes that change effective user probably aren't typical for desktops, I guess.

[Hu]

Generally, su without -l leaves many bits of the parent environment unchanged, so $XDG_RUNTIME_DIR leaking through is not surprising.

[Goverp]

Generally, su without -l leaves many bits of the parent environment unchanged, so $XDG_RUNTIME_DIR leaking through is not surprising.

Yup, thinking some more about it, an awful lot of things can break; I ought to get out of the habit of using it just to avoid changing working directory !