Hai all!
the script /usr/local/etc/rc.subr.d/var script does the following:
# setup output directory for php sessions
mkdir -p /var/lib/php/sessions
chown root:wheel /var/lib/php/sessions
chmod 750 /var/lib/php/sessions
rm -f /var/lib/php/sessions/sess_*
The problem that can manifest with this is if there are more files than can be removed in one go... and it never resolves itself.
It got bad enough that even trying to remove them in 16 chunks wasn't sufficient; so I ended up double-hashing:
D=/var/lib/php/sessions;
T=0;
for F0 in 0 1 2 3 4 5 6 7 8 9 0 a b c d e f; do
for F1 in 0 1 2 3 4 5 6 7 8 9 0 a b c d e f; do
F="${F0}${F1}";
H="sess_${F}";
CC=$( ls ${D}/${H}*|wc -l 2>/dev/null||0 );
T=$(( T + CC ));
echo -e "Matches[${F}]: ${CC}\tTotal: ${T}";
if [ ${CC} -ge 1 ]; then
echo -n "...purging ${D}/${H}*";
rm ${D}/${H}*;
echo "...Done";
fi;
done
done
I'm sure there's better ways...
I might just check to see if the dir exists at all, if so, move it, recreate it with a clean one,
(so's the directory inode is re-initialized on filesystems that directory inodes don't autoshrink)
an then purge...
¯\_(ツ)_/¯
figured I'd share here in case it bites someone else.
You seem to have a lot of GUI callers? :)
Does this work for you?
# find /var/lib/php/sessions/ -name "sess_*" | xargs rm
Cheers,
Franco
hm...
i looked into it a bit more:
this might be a more durable path forward?
https://www.php.net/manual/en/function.session-save-path.php
seems like there's an inbuilt hashdir mechanism for session files
another possible option would be to store the session files in a tmpfs dir that doesn't persist reboots?