9 ms·

systemd-tmpfiles bugs the heck out of me. It breaks so many applications for absolutely no good reason. A typical system of mine not running it gathers less t

by aidenn0 7mo ago

systemd-tmpfiles bugs the heck out of me. It breaks so many applications for absolutely no good reason. A typical system of mine not running it gathers less than 1GiB per year of uptime in /tmp with disk sizes measured in TB. Even if you are /tmp on a 256GB NVME, that's less than 1% of your total disk per year of uptime. If you upgrade to alternating Ubuntu LTS editions (which requires a reboot every 4 years) systemd-tmpfiles will save you a maximum of 4GB of disk space.

hedora 7mo ago
If you care about slow tmp leaks, you could also just use a 1-line, decade+ old solution; no additional software required, since your machine already has cron, find and xargs on it: https://askubuntu.com/questions/431058/using-a-cronjob-to-clean-tmp https://askubuntu.com/questions/431058/using-a-cronjob-to-cl... If you miss that "will this eat my system?" adrenaline rush you get from systemd-tmpfiles, you could just use cron + find, but replace xargs with the -delete option.
linsomniac 7mo ago
>which requires a reboot every 4 years We have a monitoring check and once a system reaches 200 days of uptime we start scheduling a reboot. Because you KNOW there are kernel and library updates that are probably hanging around on disc but not in memory. I used to be an uptime snob, but I've decided it does more harm than good. Slightly related: A coworker was doing a RAM upgrade on a Sun box. I suggested that before they cracked the hardware open, they first shut it down, and then power it back on, just to make sure it would. So they wouldn't go chasing down a RAM upgrade issue when it was the system itself. I want to say that this system had years of uptime since it was last rebooted, let alone powered off. He was very glad I suggested that, because it indeed did not come back up after the power cycle.

9 ms·

systemd-tmpfiles bugs the heck out of me. It breaks so many applications for absolutely no good reason. A typical system of mine not running it gathers less t

by aidenn0 7mo ago

hedora 7mo ago
If you care about slow tmp leaks, you could also just use a 1-line, decade+ old solution; no additional software required, since your machine already has cron, find and xargs on it: https://askubuntu.com/questions/431058/using-a-cronjob-to-clean-tmp https://askubuntu.com/questions/431058/using-a-cronjob-to-cl... If you miss that "will this eat my system?" adrenaline rush you get from systemd-tmpfiles, you could just use cron + find, but replace xargs with the -delete option.
linsomniac 7mo ago
>which requires a reboot every 4 years We have a monitoring check and once a system reaches 200 days of uptime we start scheduling a reboot. Because you KNOW there are kernel and library updates that are probably hanging around on disc but not in memory. I used to be an uptime snob, but I've decided it does more harm than good. Slightly related: A coworker was doing a RAM upgrade on a Sun box. I suggested that before they cracked the hardware open, they first shut it down, and then power it back on, just to make sure it would. So they wouldn't go chasing down a RAM upgrade issue when it was the system itself. I want to say that this system had years of uptime since it was last rebooted, let alone powered off. He was very glad I suggested that, because it indeed did not come back up after the power cycle.