On 23/01/14 08:51, Dylan wrote:

On 23/01/14 07:38, jdd wrote:

...

Le 23/01/2014 08:19, Dylan a écrit :

...

Hi

I was doing some general HD housekeeping recently, and found several hundred old and irrelevant files scattered through the directories under /tmp. This was surprising, since I have the "clear temp directories on boot" option set to "yes" in the YaST sysconfig editor module.

Is this no longer the 'correct' method to cleat the temp directories? How should I make sure that these directories do not become overloaded with redundant files in future?

Thanks Dylan

I just verify that this is still in the cron options in yast (13.1). From memory I think I've seen some thread saying this is deprecated, but I don't find where.

Fact is I didn't set this up (my 13.1 install is pretty fresh) and I have only 300kb of files in /tmp, not a big deal.

may be /tmp is the next candidate for tmpsfs in ram?

I hope not - I do a lot of graphics rendering and video compositing which generates lots of multi-megabyte temporary files which would rapidly overload tmpfs (unless there was an extravagant swap partition, which would have significant performance consequences...)

Dx

It's mentioned in the Release Notes. It was a change since 12.3 or 12.2. What's in YaST/Cron is no longer relevant. systemd handles cleaning of temp directories. Still, I did find on my own 12.3 machine a while back that there were several gigabytes cluttering up temp and leaving my root partition at the limit of space remaining. Looking at a lot of those files, they were dated a long time prior and had been there longer than the 30 or 90-day default temp clearance limits. I did the stupid and crass thing of simply deleting everything and rebooting because I couldn't be bothered learning all about systemd to do it the proper way, and have had problems on this machine ever since. (I'd done the same thing previously on old installs where cron handled this and it never produced a problem, FWIW). Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 23/01/2014 20:12, John Andersen a écrit :

On 1/23/2014 12:02 AM, Peter wrote:

...

I did the stupid and crass thing of simply deleting everything and rebooting because I couldn't be bothered learning all about systemd to do it the proper way, and have had problems on this machine ever since. (I'd done the same thing previously on old installs where cron handled this and it never produced a problem, FWIW).

You should file a bug report if deleting temp causes any problems at all. Temp means temp. Words have meanings. If the distro has suddenly instituted a requirement that /temp persist, its wrong headed, and needs to be fixed.

if there where a setup for this it's because what you say is not always true. that said I use a temp-dir for my temporary work (nothing to do with /tmp), and I assume that what is there can be removed if necessary... jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 23/01/14 08:15, jdd wrote:

Le 23/01/2014 08:51, Dylan a écrit :

...

On 23/01/14 07:38, jdd wrote:

...

...

may be /tmp is the next candidate for tmpsfs in ram?

I hope not - I do a lot of graphics rendering and video compositing which generates lots of multi-megabyte temporary files which would rapidly overload tmpfs (unless there was an extravagant swap partition, which would have significant performance consequences...)

with the 8Gb+ ram at present time?

Yes - a complex scene with several dynamic objects can easily reach 2Gb+ memory requirement before considering the size of textures, intermediate data caches and the final rendered image. An animation requires 24 rendered frames per second to be stored prior to post-processing (compositing.) The compositing process requires the base image and the final image to be in memory at the same time along with more intermediate structures... Storing all that in tmpfs is simply not a viable option.

I had similar problem not so long ago when duplicating Blu-Ray disks. But k3b allows the change of the temp folder.

The temp storage directory of completed frames can be changed (and I do) but the semi-persistent data caches (for object characteristics which remain unchanged between frames, for example) are kept in files created by tmpfile (from stdio.h) etc... These files can easily reach hundreds of Mb, and there can be hundreds of them in a single render session (at least one for each object in a scene.)

I never use /tmp for large files because I have it in / (root partition) that is not really bigger than ram :-)

Well, gwenview, for example, stores images downloaded from websites under /tmp somewhere, and doesn't remove them - when researching reference images this leads to many large hi-res images hanging around long after they are needed. Dx

jdd

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 23/01/2014 10:14, jdd a écrit :

found in 12.3 release notes (from google)

5.2. systemd: Cleaning Directories (/tmp and /var/tmp)

openned bug #860058 jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-23 08:38, jdd wrote:

Le 23/01/2014 08:19, Dylan a écrit :

...

This was surprising, since I have the "clear temp directories on boot" option set to "yes" in the YaST sysconfig editor module.

Is this no longer the 'correct' method to cleat the temp directories? How should I make sure that these directories do not become overloaded with redundant files in future?

That's right, the feature was removed, but the sysconfig files and setting remain. And not honoured.

I just verify that this is still in the cron options in yast (13.1). From memory I think I've seen some thread saying this is deprecated, but I don't find where.

Yes, several posts.

may be /tmp is the next candidate for tmpsfs in ram?

Past candidate. AFAIK, /tmp is a tmpfs in pure systemd setups, according to the devs. openSUSE did not agree, and /tmp remains a real directory on openSUSE systems. So, upstream, they assume that /tmp just is recreated on boot, so no need to purge it. I don't know why the openSUSE cron jobs were removed. And the systemd mechanisms to clean old files on /tmp do not work, of course. That is the state of affairs as far as I know. My memory is not perfect. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLhJEMACgkQtTMYHG2NR9WElgCeO10ty7JrZexMIXLJ+vEfn3Um 8HgAn24lxl8sgqVid4GSCyYWQssFUZDh =8VcB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 25/01/2014 09:26, Linda Walsh a écrit :

Tell me how well that would work coming out of memory for most people?

using an other folder? jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 25/01/2014 09:48, Linda Walsh a écrit :

jdd wrote:

...

Le 25/01/2014 09:26, Linda Walsh a �crit :

...

Tell me how well that would work coming out of memory for most people?

using an other folder?

---

Another "tmp" folder that would become fodder for systemd's tmpfs management?

no a folder you manage yourself

That's just moving the problem downstream.

/tmp has never been a memory limited folder -- changing it to one would be another fiasco.

/tmp was always a limited memory folder by default, being on limited / partition multiterabytes disks are not so old :-(, and having a separate /tmp partition do not solve your problem. /tmp is a system-wide temporary folder and should not IMHO hold personal large files, as an admin, I get all /tmp to be removable as needed jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/25/2014 11:44 PM, Linda Walsh wrote:

Mine hasn't been on the root partition for about 10 years.

I didn't want to destabilize root by having alot of r/w activity on the root partition, so my /tmp 'really' on my /var partition -- that was named for it's 'variable' state. mounting /var and using "rbind" to mount a dir one /tmp, is an early step.

There are and there have been in the past many good reasons to have /tmp treated differently. * once there was a vulnerability which could simply be mitigated by having /tmp on a separate partition. maybe that will recur. * some applications such a the C/C++ development cycle creates a lot of transient activity on /tmp with the intermediate files of the compile process. having /tmp on a separate spindle offers a parallelism that helps here. * in the limiting case of the above a tmpfs /tmp would make that even faster, but many applications want the memory. * Mike Tilson once developed a FS overlay that he used for /tmp which images part of the FS, the inodes and root directory, into memory in a way similar to a tmpfs. This was on 'development' machines and was a very successful accelerator. * one of the problems of DOS/Windows is that can't make the root 'read only' since it needs activity. Yes you can create a D: partition and move the swap file off C: but it still needs to have C: writeable. Not so for Linux. You can set it up, assuming you aren't doing upgrades, with the root partition READ-ONLY. Yes you need to migrate other things off the root partition and perhaps set symlinks (heck, there are a lot under /etc/ anyway!) and rbind. Having binaries and libraries RO is a great defence against hackers and malware. * partitioning is just that. it can also put a cap on abuses and mistakes. As has been pointed out with today's large disks, having a very large /tmp partition isn't a problem, but there is no need to make your whole system one files system[1]. [1] That being said, I do have a system where its all one partition - an experimental system running BtrFS, but that's also on an old 20G drive. -- Whenever men take the law into their own hands, the loser is the law. And when the law loses, freedom languishes. -- JFK -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 26/01/2014 15:57, Ted Byers a écrit :

advise such a novice how to partition, say, a new system with one or two large

I wouldn't( avice a *novice* do tweek his install, the risk of opening a breach bigger than the hole he close being large if you have really sensitive data, hire an expert jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/26/2014 09:57 AM, Ted Byers wrote:

[...] Would I be right in guessing that none of the above is an issue if you're using an SSD, since there are no moving parts in an SSD?

Not entirely. The 'no moving parts' is a side issue. There's much work been done on 'parallelism' and its all indicated that its a good thing for performance. If you make use of it, that is. One machine I used had 5-channel memory, difficult to do properly unless you use very small memory chips. That meant that TWO disk controllers and the CUP and a take drive and a debugger could all walk though memory. Just not accessing the same 512-byte bank at the same time. Why bother? Well my old PDP-11s had controllers that could manage up to 8 spindles; could seek simultaneously on all of them but only transfer from one. If I wanted to try simultaneous transfer, not exactly possible on PDP-11 memory hardware, I needed a separate controller. But overlapped seeks ... and smaller drives ... Today if we have multiple spindles we do RAID. No, the point is a separate PARTITION. Even the "above" applies with a single (large) disk drive that has been partitioned. Even the old technique Mike Tilson used was applicable for a single drive. The problem with a single drive is reliability, but that's not what I'm talking about here. If you have a SSD you can still partition it. Personally I wouldn't put /tmp on a SSD.

...

* one of the problems of DOS/Windows is that can't make the root 'read only' since it needs activity. Yes you can create a D: partition and move the swap file off C: but it still needs to have C: writeable. Not so for Linux. You can set it up, assuming you aren't doing upgrades, with the root partition READ-ONLY. Yes you need to migrate other things off the root partition and perhaps set symlinks (heck, there are a lot under /etc/ anyway!) and rbind. Having binaries and libraries RO is a great defence against hackers and malware.

Now this is interesting, as there is always a risk of attack by bad guys. Is there a comprehensive 'HOW TO' you can point to that is adequate to show even a novice how to protect himself using this practice? If not, how would you advise such a novice how to partition, say, a new system with one or two large SSDs (Crucial has had one that is almost 1TB for quite a while), so that he can make his binaries and libraries RO, for a machine intended to be a web server? And, if it is set up that way, what method would he have to use in order to be able to apply updates (particularly those related to security - there will be, for example, such updates to apache's httpd server, and whatever DB he's using, and obviously these would need to be applied so that the web apps are protected as well as can be done)?

If you stop and think about it, a LiveCD version of Linux has a read-only setup. Some of those allow you to have a USB with a writeable segment for customization. http://en.wikipedia.org/wiki/Read-only_root_filesystem I'd experiment. I'd google first, since this has been discussed many times at USENIX BOAF and other conferences. http://www.a-netz.de/2013/02/read-only-root-filesystem/ This is close to a how-to: https://sites.google.com/site/linuxpendrive/rorootfs Take a look at your system and think in terms of "if each partition was on a separate 'drive', which ones could I snip the write wire to?" You'll soon see that those 1T SSD are NOT a good idea. The problem is putting everything in one place. A mistake of MS-DOS/Windows. Certainly having /tmp on a SSD is a BAD idea. And if you have it as tmpfs in memory then you better have a way of cleaning it unless you reboot your machine to flush it daily. The reality is that you can run all of SUSE on a 20G system. I'm running a 12.3 system on a 20G drive testing out BtrFS. (Actually it less since I have a 4G Swap partition) /home is NFS mounted on a server. The problem with a large drive of any kind is that one is tempted to overload. Yes there is a trade-off; perhaps a reliable 4T drive is more failure-resistant than four 1T drives. Statistics seems to have a lot to do with it. I'm finding old, old 20G and 30G drives outlasting my much larger ones. -- The truth of a proposition has nothing to do with its credibility. And vice versa. Excerpt from the notebooks of Lazarus Long, from Robert Heinlein's "Time Enough for Love" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-01-26 23:50, Peter wrote:

Does it make any difference in your opinion to have /tmp on a separate partition on an SSD rather than lumping everything in with / ?

Having it all on the same partition spreads writes over the disk, instead of concentrating them on a smaller area. So yes, a single partition for all is better in that respect. IMO. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

On 27/01/14 00:04, Carlos E. R. wrote:

On 2014-01-26 23:50, Peter wrote:

...

Does it make any difference in your opinion to have /tmp on a separate partition on an SSD rather than lumping everything in with / ?

Having it all on the same partition spreads writes over the disk, instead of concentrating them on a smaller area. So yes, a single partition for all is better in that respect. IMO.

I can see the logic in that. I've never had a separate /tmp previously so I'll just go with my usual setup. On 27/01/14 02:55, Anton Aylward wrote:>

I don't know how modern that laptop is. Having only 4G seems small to me. But using memory for /tmp *is* an option.

The laptop is of 2008 vintage, which will doubtless seem very old to some folks but this is a recent upgrade from my nine-year-old predecessor, and aside from the slow HDD it is a very noticeable improvement for me that generally surpasses my own particular needs. So 4G RAM is already 4x what I had on my old machine!

Linux can do some marvellous things. Not only can you do tricks with mounts - rbind - but also with the overlayFS.

Having a separate /tmp you can mount it with noexec,nosuid, nodev options. That too is manages risk.

If I were you and if it were possible, I'd work out a way so that when you are at the docking station the HD is used as /tmp.

It may be as simple as a 'mount'. If the mount fails 'cos you are 'elsewhere' then the /tmp that was the mount point is used.

I toyed with this concept, not knowing how on Earth I would actually go about it, but I fear nasty repercussions. How would the system cope, when undocking it, with a load of temp files it thinks are available in a certain location no longer being there? It's not practical to have to sync everything back onto the SSD at those times, and I'm not convinced that it will capably respawn temp files as necessary. One of the reasons I'm doing this upgrade now is because I need to do a fresh install after screwing the machine up deleting everything in my /tmp a few weeks ago, following a moment where it had mysteriously filled / to the brim and no process seemed to want to do anything about it. Since I did that, I've had a multitude of problems. The laptop often refuses to suspend to RAM, or shutdown / restart / logout. Only when I have clicked a couple of times on Kickoff, brought up system activity with Ctrl-Esc and so on, after a long delay, does the logout / shutdown dialog appear. Sometimes apps like Dolphin or Kate take a minute to open. It's not like the HD's grinding away, it's dormant, but it seems like I deleted some cached file that governed these processes and which has never respawned properly. All the previous discussion about how openSUSE doesn't follow the systemd upstream defaults of clearing /tmp on boot, makes me think that until this distro resolves these issues I don't really want to start messing again with temp files by moving or deleting them, or interfering in any other way. From my perspective, the current setup is busted, because I've noticed an accumulation of temp files on a couple of other openSUSE 12.3 systems that can suddenly fill up /, and neither reboots nor the supposed systemd process that took over from sysconfig/cron for cleaning temp seems to have any effect. On my parents' machine, for example, I created a root partition of about 14GB of which about 6GB is filled after system installation, and a separate /home. Since they're in another country and I don't have remote administration set up, when I return I find their root partition is full. All they do is surf the web and check emails. This is just a bad distro default, IMO. It shouldn't ever happen.

Question: Are you using a separate partition for /home? What about /usr/local?

I always have /home separate, and /boot too. But that's as far as I go usually. My new SSD isn't huge, only 120GB. I'll be keeping a lot of personal files like music / images on portable USB-attached drives for portability to other (also v. old) machines. So splitting the root partition further isn't great as I'm not the best judge of how much space to allocate and which might then go wasted. From that perspective it's probably better to just have a larger /. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-01-28 16:05, Peter wrote:

I always have /home separate, and /boot too. But that's as far as I go usually. My new SSD isn't huge, only 120GB. I'll be keeping a lot of personal files like music / images on portable USB-attached drives for portability to other (also v. old) machines. So splitting the root partition further isn't great as I'm not the best judge of how much space to allocate and which might then go wasted. From that perspective it's probably better to just have a larger /.

A single root without a separate home (or others) has some advantages when space is limited. And disadvantages, of course. With a single partition you can not reinstall the system keeping home intact: that's the more frequent consequence. Of course, there are remedies: instead, you can do on site upgrades. Or you can make a backup, reinstall, then recover home from the backup. I understand that Ubuntu does it that way, no separate home. Another disadvantage is damage contention: with several partitions, in case of filesystem disaster, it usually limits itself to a single partition. Another is that you can not configure for specific needs, like making tmp noexec, or smaller blocks for nntp or maildir storage. Or different filesystem types. But there is the obvious advantage of not wasting space, which is important on small disks. There is no single best decision for all the multiple needs... -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

On 01/28/2014 02:37 PM, John Andersen wrote:

On 1/28/2014 8:58 AM, Carlos E. R. wrote:

...

But there is the obvious advantage of not wasting space, which is important on small disks.

You've hit the nail on the head here, because so much of Linux recommendations are from the day when that was the rule.

Splitting things out onto separate partitions wasn't a problem, because the disk sizes available pretty much required it anyway. LVM's principal reason for existence is to get around the small disk problem.

It will be interesting to see how this changes over the next decade when everyone has terabyte drives filled with mostly empty space.

LOL! It depends on what you mean by 'small'. Yes a 5 MEGAbytes drive on a PDP-11 at the end of the 70s was small, but so was the kernel and most programs. As I keep saying, I'm running an experimental BtrFS/12.3 on a 20G drive. Its usable, but for any serious work email and sub-directories of /home need to be elsewhere. I never saw LVM as a way to get around small disks. It was more an issue of (a) defer the decision about how big a partition needs to be and (b) grow partitions or (c) create a new partition and move part of one off (e.g. /usr/lib/ruby) then shrink back the original. As I've also said, when I lived solely on a laptop I never filled the 80G drive. Its only when I started saving EVERY mail message and collecting page images as PDFs that I needed a larger drive and still haven't filled a 250G drive. I've upgraded to a 1G drive for other reasons and yes it is 'mostly empty space'. I don't do BigData. -- "Each new law makes only a single guarantee. It will create new criminals." -- John Tandervold -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/26/2014 05:50 PM, Peter wrote:

On 26/01/14 17:21, Anton Aylward wrote:

...

You'll soon see that those 1T SSD are NOT a good idea. The problem is putting everything in one place. A mistake of MS-DOS/Windows. Certainly having /tmp on a SSD is a BAD idea. And if you have it as tmpfs in memory then you better have a way of cleaning it unless you reboot your machine to flush it daily.

How does this translate for an everyday user with a single SSD in their laptop / desktop? I ask because you've got me slightly worried now. On my laptop I have a slow HDD and have just ordered an SSD replacement. I do have a docking station with a modular bay so have bought a caddy to stick the old HDD in there, and will use that disk as my primary backup location.

But, this being a laptop, though I tend to use it most of the time at my desk with docking station attached, there are obviously times I go mobile with it. So I cannot put /tmp anywhere but on the main SSD. The laptop maxes out at 4GB RAM so putting temp into memory is not an option either. I can see the problem though with continual writes to /tmp not being good for an SSD's lifetime.

Does it make any difference in your opinion to have /tmp on a separate partition on an SSD rather than lumping everything in with / ?

I don't know how modern that laptop is. Having only 4G seems small to me. But using memory for /tmp *is* an option. What we are talking about here ultimately boils down to 'risk management'. You have a number of risks. Using Suse is one of them :-) Using a laptop continuously as a desktop can kill the batteries. BTDT. it keeps them on charge, warm. Batteries don't like heat. Using a single disk system is a risk. In fact using a single disk system is probably a greater risk. Linux can do some marvellous things. Not only can you do tricks with mounts - rbind - but also with the overlayFS. Having a separate /tmp you can mount it with noexec,nosuid, nodev options. That too is manages risk. If I were you and if it were possible, I'd work out a way so that when you are at the docking station the HD is used as /tmp. It may be as simple as a 'mount'. If the mount fails 'cos you are 'elsewhere' then the /tmp that was the mount point is used. Does it make a difference? It depends. On my small system running BtrFS I was trying to determine of having only one FS for the whole system allows BtrFS to do optimizations. It seems it does. Would that apply with other file systems? Perhaps with another B-Tree based FS. Elsewhere I use ReiserFS for a variety of reasons, mostly that it recovers from unexpected shut-downs very well, but I also like the way it packs small files. I make use of a lot of scripts and table-driven stuff; Ruby has a lot of script with files under 1k bytes, many half or a quarter that. For me, packing is a good thing. YMMV. There are no absolutes. Context is everything. http://ca.answers.yahoo.com/question/index?qid=20130224220113AAnFpU1 http://www.journalofaccountancy.com/Issues/2008/Feb/ShouldYouKeepYourLaptopP... http://www.reddit.com/r/askscience/comments/1mvu4f/ Question: Are you using a separate partition for /home? What about /usr/local? -- The price of liberty is eternal vigilance. --Thomas Jefferson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-01-25 09:26, Linda Walsh wrote:

Tell me how well that would work coming out of memory for most people?

Please, remember that openSUSE rejected doing that on openSUSE. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)