Andrea Turrini said the following on 05/12/2013 11:13 AM:
Second, are they really taking up space? Try running 'df' and see if your /tmp is critical.
Each directory uses at least 4k, so they are taking space.
Geez! The litter I have from printing a file is about 10 times that!
it sounds like this is an aesthetic argument, which is really unanswerable.
I see other 'junk' created in my /tmp from things like ssh, adobe, various caches, ssh and gpg, plugins to thunderbird, PPD files from CUPS (LOTS! of them!), email attachment files I've viewed, and more. All these are more significant than empty directories.
But they are removed automatically after 10 days.
And in about 10 days you're going to get an update to systemd. Hopefully. Depending on how conservative the packagers are. Lets see: we're on 195 now. That was ... [systemd-devel] [ANNOUNCE] systemd 195 Lennart Poettering lennart at poettering.net Mon Oct 22 17:56:14 PDT 2012 Oct Nov Dec Jan Feb Mar Apr so reckon on openSuse conservative stance introducing a lag of 4-6 months. Sorry, that make it more than 10 days ....
Well, what about /var/spool/postfix? Under ./defer and ./deferred there are many directories and hopefully they are empty. Are you going to add those to your list of directories to delete? Why not? Oh, right, its not an aesthetic issue.
Is /var/spool/postfix expected to be cleaned automatically? No
Yes, but you have 10 such empty directories (each taking up at least 4k, maybe more) in at least 2, maybe more, directories, on the same file system as /var/tmp! The issue isn't about whether its expected to be cleaned automatically or not. its that its there and that its taking up space. So we get back to the aesthetics issue ...
Are /tmp/systemd-private-* expected to be cleaned automatically? Yes, since /tmp was expected by upstream to be a tmpfs.
And you are quite capable of running systemctl mask to restore that. Once again openSuse is being conservative by having the default behave the old way, /tmp being on disk, rather than the 'new' way of making it a tmpfs. You want the latest, the most bleeding edge, then don't use openSuse. Either that or make use of the build service and build your own.
Personally I think you're making a big issue of something that is going to go away anyway.
Ah, just wait and then no one is allowed to complain.
Complain about a real issue then, like "opensuse is too conservative and isn't moving upstream changes into the updates fast enough for me". Because that's the real issue here. See http://lists.freedesktop.org/archives/systemd-devel/2013-March/009933.html Note the date on that - MARCH 26th. <quote> CHANGES WITH 199: * [...] * Behaviour of PrivateTmp=, ReadWriteDirectories=, ReadOnlyDirectories= and InaccessibleDirectories= has changed. The private /tmp and /var/tmp directories are now shared by all processes of a service (which means ExecStartPre= may now leave data in /tmp that ExecStart= of the same service can still access). When a service is stopped its temporary directories are immediately deleted (normal clean-up with tmpfiles is still done in addition to this though). </quote> Note that - "When a service is stopped its temporary directories are immediately deleted" So complain, yes, but complain about the right thing, which is that openSuse is too conservative for YOUR tastes. Oh, and BTW - there's the list to subscribe to :-) What puzzles me is this. All that 'research' took just a few tries at googling. The cut-and-paste took longer. How come no-one else looked that up? Its not as if there's any PhD level smarts involved in me doing a google search. Now let me ask another question. Has anyone used the build service to build a v199 of systemd? If the answer to that is "yes" then Andrea can add that repository and update systemd and LO! the problem is fixed. -- I suspect that, over time, all bureaucratic processes decay into cargo cults unless regularly challenged by a hostile reality. - Alan Rocker, 23-Nov-2011 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org