[opensuse-factory] lots of /tmp litter
TW 20170314 host gx760, originally installed 25 months ago, has, dating back over a year, through today: 117 /tmp/dracut* files 30+ /tmp/systemd-private* dirs 30+ /tmp/<10 digit number> dirs (TDE-related: twinrc & twinrulesrc) How can I find out why these persist? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 15 March 2017 at 09:11, Felix Miata <mrmazda@earthlink.net> wrote:
TW 20170314 host gx760, originally installed 25 months ago, has, dating back over a year, through today:
117 /tmp/dracut* files
Are you doing something weird with dracut? My system doesn't have any dracut* files in tmp and I've been mkinitrd-ing my ass off lately after I accidentally configured salt to run it every time my system refreshed its configuration.
30+ /tmp/systemd-private* dirs
These are to be expected
30+ /tmp/<10 digit number> dirs (TDE-related: twinrc & twinrulesrc)
TDE doesn't correctly configure /usr/lib/tmpfiles.d to tidy up after itself? Shame.
How can I find out why these persist?
Generally speaking the answer is simple - because your /usr/lib/tmpfiles.d (or /etc/tmpfiles.d overrides) are allowing them to persist. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
OP omitted info that might be relevant: /tmp is a separate 5GB filesystem on a multiboot system with 13.1, 42.1, 42.2 & TW. The particular machine doesn't get much actual use. It's connected to my TV, which spends most of its on time playing DVB from standalone devices. Richard Brown composed on 2017-03-15 09:30 (UTC+0100):
Felix Miata wrote:
TW 20170314 host gx760, originally installed 25 months ago, has, dating back over a year, through today:
117 /tmp/dracut* files
Are you doing something weird with dracut? My system doesn't have any dracut* files in tmp and I've been mkinitrd-ing my ass off lately after I accidentally configured salt to run it every time my system refreshed its configuration.
The subject machine, and this one, each use one separate filesystem for /tmp, used by whichever oS is booted. This one, running 42.1, currently has 37 such files on /dev/md0 dating back to 18 Nov. I delete them manually when I notice them piling up. I don't know that I'm "doing anything" with dracut, wierd or otherwise. It gets used here very rarely other than during installation of new kernels. The only unusual thing I'm aware of is that most TW kernels here get installed by my running rpm -ivh. On first exposure to availability of new release and TW kernels, I wget each once to the LAN server, then install "manually" instead of zypper downloading again for each machine that wants it. The procedure saves some bandwidth, and allows me to see at a glance exactly when any particular (saved) kernel version became available.
30+ /tmp/systemd-private* dirs
These are to be expected
30+ /tmp/<10 digit number> dirs (TDE-related: twinrc & twinrulesrc)
TDE doesn't correctly configure /usr/lib/tmpfiles.d to tidy up after itself? Shame.
It's OK for systemd to not tidy up after itself, but not TDE???
How can I find out why these persist?
Generally speaking the answer is simple - because your /usr/lib/tmpfiles.d (or /etc/tmpfiles.d overrides) are allowing them to persist.
It doesn't look so simple to me. /etc/tmpfiles.d/ is empty. TW's /usr/lib/tmpfiles.d/ contains 23 files, none of which are named starting with dracut or ########## or systemd-private. tmp.conf in the latter does have a comment that SUSE policy is to not clean /var/tmp or /tmp, and another that it's part of systemd. It looks like understanding how it works enough to improve on the defaults would require a course worth 2-3 college credits, aka, not simple. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 15/03/17 05:40 AM, Felix Miata wrote:
It doesn't look so simple to me. /etc/tmpfiles.d/ is empty. TW's /usr/lib/tmpfiles.d/ contains 23 files, none of which are named starting with dracut or ########## or systemd-private. tmp.conf in the latter does have a comment that SUSE policy is to not clean /var/tmp or /tmp, and another that it's part of systemd. It looks like understanding how it works enough to improve on the defaults would require a course worth 2-3 college credits, aka, not simple.
I'm sure this has been discussed before here because I have in my /etc/tmpfiles.d/ a, I resume custom, file named remove-systemd-private.conf It seem an name unlikely to have been installed by the system. It looks like it cleans out the systemd-private files at boot time. Indeed, as you say, tmp.conf, excludes the systemd-private -* with the comment: <quote> # Exclude namespace mountpoints created with PrivateTmp=yes </quote> That probably requires an explanation at the level of your college course. -- Operationally, God is beginning to resemble not a ruler but the last fading smile of a cosmic Cheshire cat. Sir Julian Huxley -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Anton Aylward -
Felix Miata -
Richard Brown