I noticed here that Alan warned about making sure /tmp had space enough to allow for large file uploads, but I was monitoring df during the upload process for a 1.5 GB file and noticed…
- /tmp does temporarily grow, but by 3.0GB instead of the 1.5GB expected
- my /var grew by 1.5GB too!
I’m curious if either/both of these are normal, or maybe something I’ve done? And if this is just the way it works, it might be worth warning about in the doc. Even more interested in learning if the /var component is controllable!
Before upload starts…
Just before upload completes (highlites were from watch)…
No symlinks, btw
[root@ondemand-dev jtb49]# ls -ld /var /tmp /var/tmp
drwxrwxrwt. 8 root root 4096 Feb 3 13:00 /tmp
drwxr-xr-x. 22 root root 4096 Jan 9 2024 /var
drwxrwxrwt. 7 root root 4096 Jan 12 01:06 /var/tmp
Just a followup, in case anyone else wanted to examine their instance.
For a while I was confused why I couldn’t find the file that was blowing up /var. I suspected it was in /var/tmp/ondemand-nginx/jtb49 … but a find . -mmin -1 command wasn’t showing me what I was hunting for
A lsof did show a “deleted” file that was tied to the upload (eg: “/proc/1386416/fd/8 => /var/tmp/ondemand-nginx/jtb49/client_body/0000000001 (deleted)”)
I made a simple watch-script to show me how /var and /tmp varied, as well as the handle from the upload process:
#!/bin/bash
out=/root/ood-up2.txt
while true; do
date '+%s' | tee -a $out
df /var /tmp | tee -a $out
find /proc/[0-9]*/fd -lname '*(deleted)' \
-printf '%p => %l\t' \
-exec stat -Lc '%s' {} \; 2>/dev/null |\
grep jtb49 | tee -a $out
sleep 0.5
done
And visualized the parsed data to see I wasn’t imagining things: /var grows by the size of the upload, and /tmp grows double (!!).
The nginx_stage.yml could be used to control this, but I thought that that was more of an interactive-apps thing?
[root@ondemand-dev ~]# grep -B2 var.tmp /etc/ood/config/nginx_stage.yml
# Root location of per-user NGINX tmp dirs
#
#pun_tmp_root: '/var/tmp/ondemand-nginx/%{user}'
