- On 02/19/2018 03:09 PM, yk+bug+x2go@64.re wrote:
On Linux, the X2Go server stores the session files in /tmp/.x2go-* . Now, whenever a coworker leaves for vacation, those files are not getting updated and thus get deleted by tmpwatch on CentOS 6 or systemd-tmpfiles on CentOS 7; when the coworker comes back and tries to resume the session, it goes into failed mode since those files are gone, with no possibility of recovery. The current workaround that I set up is to exclude /tmp/.x2go-* from clean-up (e.g.[1]), but to prevent having to do it on every machine to which we want to connect, it would be nice to move the folder to a place that is not cleaned (at least as often).
This is why nightly and upcoming release builds already contain such a systemd-tmpfiles config file to counter this deletion.
Although the Linux Filesystem Hierarchy Standard (FHS) has been widely disputed, it seems to be an admitted convention to put PID/lock/socket files and the like in /run (or /var/run). Is there a specific reason why those files are in /tmp and not in /var?
These files used to be put in the users' home directory, but this turned out to be a bad idea (of some sort at least), since they are really local to one machine, i.e., the one running the corresponding X2Go session. Since the home directory might be on an NFS share, it would have been synced over the network, which is useless, produces unnecessary load and has higher latency than a local on-disk location.
Subsequently they were moved to /tmp instead, which should be machine-local.
Nowadays, /run or /var/run should also be machine-local and hence more or less appropriate, but I do not know if that is also true for older operating systems (CentOS 6, SLE 11)? The next problem could be that these directories might be polyinstantiated into private directories somewhere else, which would make it way more difficult (if possible at all) to access files and directories in there via another user (think the client-side printing spool/client-side file sharing mount directories).
Mihai