Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern demo sites - status updates, issues, downtime, et cetera
Yay, nice sleuthing. Glad you found the culprit and were able to fix it.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Textpattern demo sites - status updates, issues, downtime, et cetera
Nice digging deep into dark holes there… Hopefully next round will go better.
A heavy serve amount of “ai“ would not help much :/
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: Textpattern demo sites - status updates, issues, downtime, et cetera
I have a resource usage alarm set at DigitalOcean and it emails me when the CPU / drive hits 80% for more than 10 minutes. Last night I got the email for high CPU usage, and managed to catch it before the thirsty process bailed out. It wasn’t clear from ps or htop what had triggered the process, but anecdotally I expect a Netdata recompile around midnight on release days. A check on the existing Netdata showed it was stuck on the prior version (i.e., there had not been an updated to the most recent release). Pushing an install of the current release has hopefully fixed things.
Compiling Netdata from source on that server takes around 1 hour to complete. An automated update takes less time, usually…and it’s automated so I don’t get affected by it. There’s barely any practical difference in the end result when using the Netdata source compile vs the vendor-supplied repository release, but the latter installs in seconds vs an hour. Because the current demo server is of a certain age, I was all about the source compile back then…now I use the repo release and get on with my day. The next iteration of donald will be using the repo.
Another factor that I seemed to have stumbled on is how /tmp is handled on Debian 13. According to release notes and multiple articles, /tmp on Deban 13 is now essentially a RAM disk rather than a traditional file system volume:
lowendbox.com/blog/a-deep-dive-into-debian-13s-tmp-whats-new-and-what-to-do-if-you-dont-like-it/
Given a lot of the servers I use have modest RAM and swapfile setups, this could get pretty bad rather quickly. Suffice to say, I’ll be changing /tmp to use the drive and not the RAM.
Last edited by gaekwad (Yesterday 09:15:51)
Offline
Re: Textpattern demo sites - status updates, issues, downtime, et cetera
How to move Debian 13 /tmp from tmpfs (RAM disk) to disk
(Note: this will remove / delete anything in /tmp)
sudo systemctl mask tmp.mount…then reboot.
Use df to check for /tmp: if the ‘Filesystem’ is tmpfs, /tmp is using the RAM disk…if it’s not listed, /tmp is using the disk.
Offline