Your right /tmp is not a tmpfs by default on Debian. I though it was,
maybe being too much used to it as this is configured by default on our
images. /dev/shm or /run would work better then, although /run IMO is
more aimed for non-temporary files, relevant through the whole runtime
of the related process or system, while /tmp is more aimed for
short-term temporary files. However it was/is not my choice to use /tmp
in the particular case and out of my control.
Background, if interested:
-------
In my particular case where I ran into the issue, it is a 3rd party
software that chooses to store information to /tmp/<something> via sub
process which is then read by originating process. Indeed the
circumstance is a bid special, the solution is even commented as an
"ugly" one within the code, but no better method had been found until
now. The software collects information about the Python environment by
doing a dummy module install (that is aimed to fail). The dummy modules
installer collects info about where it was installed to
(venv/user-level/system-level, ...) and writes that to /tmp/<something>
to be read by the originating Python script. It has an internal updater
which invokes pip the "correct" way based on the /tmp/<something>
content (e.g. --user flag or not).
I want the software to run as system service with an own limited user,
but aim to have it installed as global/system Python module to
/usr/local/lib|bin instead of in --user mode into its own UNIX user home
directory, or as vnev, to prevent doubled Python module installs (target
is small embedded systems with potentially limited disk space), easier
access/maintenance for the real (login) user and clear separation
between data/config and the Python modules. To retain the functionality
of the internal updater, it requires specifically limited "sudo pip
install <itself+dummy>" permissions to self-upgrade and do it's Python
environment collection dummy install that is out of my control. The
problem is now that it pre-creates /tmp/<something> as its limited
service user but since pip is called via sudo, the dummy installer then
tries and fails to write to that file as root user.
-------
I am actually sort of Linux distributor, more precisely developing
Debian-based images mostly for ARM SBCs together with a tool set to
easily install and configure system a bunch of software titles. See the
domain of my mail address. If I was a system administrator only, of
course, why should I feel forced to follow any standard, but as a
software developer I clearly disagree with you! The FHS is exactly what
software developers should then be able to count on and respect
themselves (to allow others count on it), which directories are present
and used in the same (at least similar) way by the distributions own
software packages as well as most 3rd party software installers. Without
FHS one would quickly have all sorts of files messed across a bunch of
different directory structures and sub structures, making it impossible
for admins to follow any logic to find certain types of files, like
software and system configuration files, variable data, temporary files
etc, also to know where files are expected to survive a reboot and where
not (potentially tmpfs) etc. Without FHS (or any other standard across
Linux/UNIX systems) we had a mess, so FHS is no "crap" but very valuable
and important, IMO.
But that is a discussion that has nothing to do with the originating
issue, which has been identified thanks to your help! :)
It's now a bid others and whether the default has actually been changed
intentionally, and if so more like "why not" or if there have been
actual concerns, serious enough to change a default, which implies
different and probably unexpected behaviour. And if so, if there is a
plan to have this documented a bid wider.
Best regards and stay healthy,
Micha
