-SNIP-

let's keep /tmp on disk for at least one more release...

/Jos

* note how I did NOT abuse Lennart Poettering in any way. He's supposed to invite me for dinner sometime soon and I want to survive his food.

Keep on disk -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Mar 28, 2012 at 11:47 PM, Peter Linnell wrote:

...

...

* note how I did NOT abuse Lennart Poettering in any way. He's supposed to invite me for dinner sometime soon and I want to survive his food.

Keep on disk

+1 for at least another release cycle.

I agree, like I said on the other thread, to be able to test it properly it has to be done first thing in the release cycle. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

For reference, 2GB is very very far away from my experience (after 20 days of uptime). It might be worth investigating why it's so big for you -- and we can help fix the broken apps like thumbnailers.

I have been below and above this figure. Yes, we can fix {some} apps. And afterwards, we can have tmpfs if we like to. I don't think the gains warrant the discussions we currently have on this issue. - -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk90AhkACgkQCs1dsHJ/X7DqwACg8kFyaLRZJi7OVY6lS/UQ5P99 FQoAniozbRF7I06nIoChXGlZv0lO8Hgz =6FSe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 29 March 2012, Frederic Crozat wrote:

Le jeudi 29 mars 2012 à 08:01 +0200, Vincent Untz a écrit :

...

Le mercredi 28 mars 2012, à 21:10 +0200, Jos Poortvliet a écrit :

...

To get something out of the way: if you run your DESKTOP system more than a week or two, expect /tmp to grow BIG. 2 GB is nothing in my experience. Thumbnailers sometimes leave data behind and so do things like flash, web browsers, inkscape, transcoding apps, CD Burners, some compiles ... This might be due to apps misbehaving but we're not Fedora, we handle the world as it is - not as it should be.

For reference, 2GB is very very far away from my experience (after 20 days of uptime). It might be worth investigating why it's so big for you -- and we can help fix the broken apps like thumbnailers.

I share this feeling, I currently have 12MB, with 4MB because of me. The bigest consumer of /tmp is temporary files downloaded by Firefox for external files, like PDF (Evince).

BTW you have to watch the peaks rather than a state at random time. Just one example: Open a large 'zipped text file using less (lessopen.sh) and see what happens in /tmp.

...

Also, by default, we clean files in /tmp that are older than 10 days. It might help with the switch to tmpfs.

This major change has never been announced or documented for 12.1. The behavior is different on systemd and sysvinit systems. I'd call it a bug allthough 10 days may be a good default. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 29 March 2012, Carlos E. R. wrote:

On 2012-03-29 11:21, Ruediger Meier wrote:

...

This major change has never been announced or documented for 12.1. The behavior is different on systemd and sysvinit systems. I'd call it a bug allthough 10 days may be a good default.

Not if your uptime is bigger than 10 days.

If you only want to clear it on reboot then you have to disable the daily cleanup anyway. IMO 10 days would be a good default according to FSH. Unfortunately suse has never cleaned up /tmp per default in past (not even on reboot!). Very bad style to change this silently. BTW I'm using this on the desktops MAX_DAYS_IN_TMP="120" MAX_DAYS_IN_LONG_TMP="365" The uptimes are usually longer than 120d and also often longer than 365d but that's ok for me. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Ruediger Meier wrote:

On Thursday 29 March 2012, Frederic Crozat wrote:

...

Le jeudi 29 mars 2012 à 08:01 +0200, Vincent Untz a écrit :

...

Le mercredi 28 mars 2012, à 21:10 +0200, Jos Poortvliet a écrit :

...

To get something out of the way: if you run your DESKTOP system more than a week or two, expect /tmp to grow BIG. 2 GB is nothing in my experience. Thumbnailers sometimes leave data behind and so do things like flash, web browsers, inkscape, transcoding apps, CD Burners, some compiles ... This might be due to apps misbehaving but we're not Fedora, we handle the world as it is - not as it should be.

For reference, 2GB is very very far away from my experience (after 20 days of uptime). It might be worth investigating why it's so big for you -- and we can help fix the broken apps like thumbnailers.

I share this feeling, I currently have 12MB, with 4MB because of me. The bigest consumer of /tmp is temporary files downloaded by Firefox for external files, like PDF (Evince).

BTW you have to watch the peaks rather than a state at random time. Just one example: Open a large 'zipped text file using less (lessopen.sh) and see what happens in /tmp.

...

...

Also, by default, we clean files in /tmp that are older than 10 days. It might help with the switch to tmpfs.

This major change has never been announced or documented for 12.1.

I don't think it quite works either - /etc/sysconfig/cron clearly says: # cron.daily can check for old files in tmp-dirs. It will delete all # files not accessed for more than MAX_DAYS_IN_TMP. If MAX_DAYS_IN_TMP # is not set or set to 0, this feature will be disabled. # MAX_DAYS_IN_TMP="0" ## Type: integer ## Default: 0 # # see MAX_DAYS_IN_TMP. This allows to specify another frequency for # a second set of directories. # MAX_DAYS_IN_LONG_TMP="0" The above is from a system with plain 12.1+updates+systemd. It looks like files are being cleared out, but not directories?

The behavior is different on systemd and sysvinit systems.

Ah, that's new. -- Per Jessen, Zürich (16.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 29 Mar 2012 08:01:32 Vincent Untz wrote:

Le mercredi 28 mars 2012, à 21:10 +0200, Jos Poortvliet a écrit :

...

To get something out of the way: if you run your DESKTOP system more than a week or two, expect /tmp to grow BIG. 2 GB is nothing in my experience. Thumbnailers sometimes leave data behind and so do things like flash, web browsers, inkscape, transcoding apps, CD Burners, some compiles ... This might be due to apps misbehaving but we're not Fedora, we handle the world as it is - not as it should be.

For reference, 2GB is very very far away from my experience (after 20 days of uptime). It might be worth investigating why it's so big for you -- and we can help fix the broken apps like thumbnailers.

Also, by default, we clean files in /tmp that are older than 10 days. It might help with the switch to tmpfs.

I'm in agreement, I don't see a heavy usage pattern in /tmp at all. I would like that the default be tmpfs for /tmp, I have this already on my workstations and it aligns with my future plans for servers as well. However I see the concerns of the list and understand where they come from having had a couple of apps fail due to a filled up /tmp dir. If we don't do this as a default for 12.2, let's please get it on the agenda for 12.3 and we can get the word out early. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday, March 29, 2012 17:21:11 Cristian Rodríguez wrote:

El 28/03/12 16:10, Jos Poortvliet escribió: But for now -

...

let's keep /tmp on disk for at least one more release...

Well, I disagree :-) what you are essentially proposing is not adopting this scheme due to the existent of corner cases and buggy software, not good enough for me.

This is what I believe must be done:

- For system daemons, turn on PrivateTmp in systemd .services when applicable (list of packages --> https://bugzilla.redhat.com/show_bug.cgi?id=782466) This ensures that temp files are only available to the daemon process and if it crashes or misbehaves files will be deleted on spot.

Yes, good idea.

- For users, implement what Lnussel and fcrozat suggested, a separate tmp per user in /run/<user>/ tmpfs.

Yes,I'm in favor of this as well.

Otherwise temporary file creation bugs will keep biting us forever.

- Fix buggy software if any.

Still I would leave /tmp per default as a normal directory and allow tmpfs usage for those that want it. Or enable tmpfs only on new installs with enough memory, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Mar 29, 2012 at 10:30 AM, Andreas Jaeger wrote:

Or enable tmpfs only on new installs with enough memory,

I have a problem with this. As I see it, you'll end up with two different default configs - making "gee, why is my system behaving differently than yours" type of issues harder to track down. Pick *a* default and stick with it, and provide choice to users, because ultimately _users_ know (or are supposed to know) their needs best. -- Jon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Mar 29, 2012 at 12:41 PM, Cristian Rodríguez wrote:

...

If a process crashes I'm probably going to *want* those files as they are pertinent to the state of the software at the time of crash.

If software crashes, we have pretty good debuggers to detect such issues.

Not only that, logs don't go in /tmp. Logs go in /var/log. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Mar 29, 2012 at 11:00 AM, Claudio Freire wrote:

On Thu, Mar 29, 2012 at 12:41 PM, Cristian Rodríguez wrote:

...

...

If a process crashes I'm probably going to *want* those files as they are pertinent to the state of the software at the time of crash.

If software crashes, we have pretty good debuggers to detect such issues.

Not only that, logs don't go in /tmp. Logs go in /var/log.

I did not say or mean "logs". I meant "files" - in this case, temporary files that can provide insight into the cause of failure. temporary files are by definition part of the running state of the software, and if software crashes (and provides a core file) the contents of those temporary files may be critical in determining the ultimate cause of the failure. I don't care if it's the default to wipe away temporary files but it does need to be something that can be turned off without a lot of difficulty. -- Jon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 29/03/12 13:37, Jon Nelson escribió:

I did not say or mean "logs". I meant "files" - in this case, temporary files that can provide insight into the cause of failure. temporary files are by definition part of the running state of the software, and if software crashes (and provides a core file) the contents of those temporary files may be critical in determining the ultimate cause of the failure.

No! programs that crash must be run on a debugger separated from the init system whatever it is ! then you may be able to recover the "temporary" files if not already unlinked by the OS... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le vendredi 30 mars 2012 à 08:44 +0200, Michal Kubeček a écrit :

On Thursday 29 of March 2012 14:45EN, Cristian Rodríguez wrote:

...

No! programs that crash must be run on a debugger separated from the init system whatever it is ! then you may be able to recover the "temporary" files if not already unlinked by the OS...

In theory, yes. But the real world is not that easy. Many crashes result from obscure race conditions which are either not reproducible in a debugger or are extremely difficult to reproduce, some even only happen once and you are unable to reproduce them no mattery how hard you try.

It is of course nice when you have a decent bug you can reliably reproduce in a debugger and a test environment. But too often the post mortem analysis is all you have.

I think this demonstrate the need to setup abrt support for openSUSE to be able to collect crash traces as they appear. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, 2012-03-29 at 17:30 +0200, Andreas Jaeger wrote: ...

Still I would leave /tmp per default as a normal directory and allow tmpfs usage for those that want it. Or enable tmpfs only on new installs with enough memory,

Nice idea! something like a check-box in yast, that is either on/off depending on the amount of mem. Either way, i would recommend a paragraph about its merrits/dangers of tmpfs in the installation/admin manual... hans -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Ruediger Meier writes:

...

...

Also, by default, we clean files in /tmp that are older than 10 days. It might help with the switch to tmpfs.

This major change has never been announced or documented for 12.1. The behavior is different on systemd and sysvinit systems. I'd call it a bug allthough 10 days may be a good default.

At least, there is a somehow related snippet in the updated release notes (strange, the file (version 12.1.7) at http://www.suse.com/releasenotes/i386/openSUSE/12.1/RELEASE-NOTES.en.html is outdated): systemd: Cleaning Directories (/tmp and /var/tmp) ================================================= systemd maintains directories as specified in the tmpfiles.d directories and in /lib/systemd/system/systemd-tmpfiles-clean.timer. For more information, see the tmpfiles.d manpage. By default, systemd cleans tmp directories daily as configured in /usr/lib/ tmpfiles.d/tmp.conf: d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d Note: systemd does not honor sysconfig variables in /etc/sysconfig/cron such as TMP_DIRS_TO_CLEAR. -=-=-=-=-=-=-=-=-=-=-=-=-=- cut here -=-=-=-=-=-=-=-=-=-=-=-=-=- If more documentation is wanted, you are encouraged to create appropriate bug entries or send patches. The XML sources of the manuals are available from svn.opensuse.org. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2012-03-29 at 14:45 -0300, Cristian Rodríguez wrote:

No! programs that crash must be run on a debugger separated from the init system whatever it is ! then you may be able to recover the "temporary" files if not already unlinked by the OS...

That's the second time it happens, if you can reproduce it. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk91qVMACgkQtTMYHG2NR9WeMgCgi+DpTdutEz445DdM+4JXBoNE dmAAoIHiIPx+bVU27WqpxbzBQLetH28H =4TQI -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2012-03-28 at 13:22 -0700, Steven Hess wrote:

+1

+1 - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk91qywACgkQtTMYHG2NR9WuOACdEZZjni5q+cttIgTrPNw0EDS/ gsgAmgJaWye9QaB24tDBTu+TITOwnX4x =VTV3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Guenther writes:

On Fri, 30 Mar 2012, Karl Eichwalder wrote:

...

systemd: Cleaning Directories (/tmp and /var/tmp) =================================================

systemd maintains directories as specified in the tmpfiles.d directories and in /lib/systemd/system/systemd-tmpfiles-clean.timer. For more information, see the tmpfiles.d manpage.

By default, systemd cleans tmp directories daily as configured in /usr/lib/ tmpfiles.d/tmp.conf:

d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d

Note: systemd does not honor sysconfig variables in /etc/sysconfig/cron such as TMP_DIRS_TO_CLEAR.

Instead of noting that TMP_DIRS_TO_CLEAR is ignored we should remove those now pointless variables (given that for 12.2 systemd will be mandatory?)

Probably. You can clone https://bugzilla.novell.com/show_bug.cgi?id=735027 where this feature was initially tracked. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/30/2012 11:04 AM, Ludwig Nussel wrote:

Cristian Rodríguez wrote:

...

- For users, implement what Lnussel and fcrozat suggested, a separate tmp per user in /run/<user>/ tmpfs. Otherwise temporary file creation bugs will keep biting us forever.

I'm in favor of a per user $TMPDIR. I didn't say I like having it in /run/ ie tmpfs. tmpfs of course has the advantage of avoiding fragile and racy cleanup operations, at least on systems with short uptimes. In fact I use tmpfs myself for /tmp on my EEE PC with SSD. I don't use that system for any serious work though. I doubt it is a good idea for a general purpose installation to put TMPDIR on tmpfs. So I'd rather like to see TMPDIR per user, on persistent storage. The exact location would be the next controversial subject then though I guess :-)

I blogged about this thread: http://jaegerandi.blogspot.de/2012/03/tmp-as-tmpfs-for-opensuse.html Lennart commented on my post with two points - one adressing your point above and the other that it's easy to revert the default: "AJ, if you want private /tmp directories for users, I'd suggest to use kernel namespaces for that (there's a PAM module for that), instead of relying on $TMPDIR. This might break a few things which expect that /tmp is shared though, but is more comprehensive and secure, and leaves $TMPDIR to the admin and user (Which I think is a good thing). It also mimics more closely what we do for services with PrivateTmp=yes. On Fedora our plan is to turn on tmpfs on /tmpd early in the development cycle, then we'll see how much stuff breaks, and whether we can fix it all. If it's too much we simply revert back shortly before the release. Since this is an easy thing to turn on or off this should be fairly risk-less. Without turning it on in the development distro it's really hard to know what actually really breaks. Hence I can only enocurage you to turn this on early in the development distro, but be ready to turn it off again before the release if too many things break." Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 30/03/12 11:54, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2012-03-30 16:44, Andreas Jaeger wrote:

...

On Fedora our plan is to turn on tmpfs on /tmpd early in the development cycle,

/tmpd? Not /tmp? Thus /tmp would be left alone? :-?

It is a typo... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Mar 30, 2012 at 11:44 AM, Andreas Jaeger wrote:

Lennart commented on my post with two points - one adressing your point above and the other that it's easy to revert the default:

For once I'm in complete agreement with Lennart. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Guenther wrote:

On Fri, 30 Mar 2012, Karl Eichwalder wrote:

Instead of noting that TMP_DIRS_TO_CLEAR is ignored we should remove those now pointless variables (given that for 12.2 systemd will be mandatory?)

Really, it will? No more reverting to sysvinit? -- Per Jessen, Zürich (14.5°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 30/03/12 14:33, Per Jessen escribió:

Richard Guenther wrote:

...

On Fri, 30 Mar 2012, Karl Eichwalder wrote:

Instead of noting that TMP_DIRS_TO_CLEAR is ignored we should remove those now pointless variables (given that for 12.2 systemd will be mandatory?)

Really, it will? No more reverting to sysvinit?

That's a different topic.. however sysvinit is included because there were some rough edges in systemd, it would make sense to remove it once the most ugly problems are fixed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Mar 30, 2012 at 09:00:16PM +0200, Per Jessen wrote: [ 8< ]

Perhaps it's better to keep it [sysvinit] until it has become largely unusable due to lack of maintenance?

At the moment both init systems have issues as stressed in this or a different thread before.¹ Please consider to add this input to the wiki page as suggested in a different reply. We need the pros and cons at one central and easy to spot location.² As long as the raised issues are not solved we can't switch to either of both only.

It doesn't hurt to have it around, and the systemd problems sofar have no doubt made many people revert to sysvinit or postpone/skip upgrading to 12.1.

Correct. Plus we have to ensure not to switch any upgrade post openSUSE 11.4 from sysvinit to systemd again. Cause those decided to go the sysvinit route very likely do intend to stay with it. Even more important we might even annoy them more by our ignorance. Cheers, Lars ¹ https://bugzilla.novell.com/show_bug.cgi?id=730193 shutdown/poweroff/reboot hangs when using sysvinit https://bugzilla.novell.com/show_bug.cgi?id=728947 insserv tries to use systemd even when booted with sysvinit https://bugzilla.novell.com/show_bug.cgi?id=727770 sysvinit: kexec says "Failed to talk to init daemon." https://bugzilla.novell.com/show_bug.cgi?id=696902 systemd as default boot handler (replacing sysvinit) for 12.1 This is the systemd meta bug https://bugzilla.novell.com/show_bug.cgi?id=749035 System hangs after entering Runlevel 0 on a sysvinit Shutdown (cause known) ² http://lists.openSUSE.org/opensuse-factory/2012-03/msg00661.html -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-31 00:34, Brian K. White wrote:

And as has been mentioned already, most often, if an app is using a file in /tmp, it's for a reason. In case the implication of that blows by you it means if the app developer wanted to use ram, he'd have used ram. If he wanted to use per-user file space he'd have used ~/tmp.

Absolutely. If the programmer wanted to use ram, he would have used ram directly, and not use a file in /tmp, not knowing at the time that it would be saved in ram, and then into disk as swap in some cases - and thus spoiling his design decisions. It is the programmer who decides what to use for that temporary storage and how best to implement it for his program. Changing this at the system level for all programs can not work properly. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk92QWAACgkQIvFNjefEBxp+SACgvxtWxHHYviGEIcIb2fbBLpms wBcAn3kifm5ca+dI+oWxbrs7n70lpjfP =0Cwm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 30/03/12 19:34, Brian K. White escribió:

. Even ~/tmp isn't necessarily safe since /tmp has already been well defined for ages as a single shared space.

Being defined since years do not equal it is good or appropiate now. There are

apps that _rely_ on that fact and use /tmp as a form or inter-process communication, and others where it's not exactly required, just stupid and inefficient to have every user have their own redundant identical copy of some large file(s). And as has been mentioned already, most often, if an app is using a file in /tmp, it's for a reason. In case the implication of that blows by you it means if the app developer wanted to use ram, he'd have used ram. If he wanted to use per-user file space he'd have used ~/tmp. Sometimes /tmp is used either unnecessarily or even wrongly, but it's not for YOU to unilaterally accuse ALL software of that, and change the definition of /tmp right out from under 30 years of unix software.

Wow, really ? is that the best you have? a fallacious appeal to tradition ? Unfortunately your opinion does not change the facts that we have to fix tons of bugs, in a weekly manner where software screws up this very fragile misfeature.

Suse isn't a wristwatch or a router or a game console where the totality of the installed software and it's usage and behavior are all finite and addressable. Everything you personally haven't seen isn't "corner cases that don't matter".

It's the other way around. Your singular lack of experiencing a wide variety of situations is the corner case that doesn't matter.

Well, let see who's proposal succeeds and gets implemented. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2012-03-30 at 18:34 -0400, Brian K. White wrote: <trim>

The answer isn't to try to think of every possible occurrence and somehow come up with an answer for them all. The answer is to realize that the uses for /tmp are unknowable on a general-purpose OS and therefor it's not something that should be changed by default on a general-purpose OS. Even ~/tmp isn't necessarily safe since /tmp has already been well defined for ages as a single shared space. There are apps that _rely_ on that fact and use /tmp as a form or inter-process communication, and others where it's not exactly required, just stupid and inefficient to have every user have their own redundant identical copy of some large file(s). And as has been mentioned already, most often, if an app is using a file in /tmp, it's for a reason. In case the implication of that blows by you it means if the app developer wanted to use ram, he'd have used ram. If he wanted to use per-user file space he'd have used ~/tmp. Sometimes /tmp is used either unnecessarily or even wrongly, but it's not for YOU to unilaterally accuse ALL software of that, and change the definition of /tmp right out from under 30 years of unix software.

<trim> So, People should remember what "tmp" is for. A general-purpose bitbucket, that anybody can use as scratchpad (allowing to circumvent a strict limit on home-directories) while his program runs. No promises for how long it remains there. Could be weeks, or just five minutes... Some traditional unices don't even bother removing files there, they just do a "newfs" after reboot. But afaicr, there there never was an explicit reference to the available space there, although limiting it to the amount of RAM+swap isn't quite sensoble, not? In the ever continuing quest for faster responding systems, tmpfs has obviously advantages. Whether or not /tmp should be one of them is debatable. If you want lightning fast scratchpad: absolutely! If you are sloppy (forgetting to cleanup) also. If you want to accomodate resource-pigs, absolutely not. hans -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 31/03/12 16:05, Brian K. White wrote:

On 3/30/2012 8:04 PM, Cristian Rodríguez wrote:

...

Well, let see who's proposal succeeds and gets implemented.

Popularity in no way implies quality. McDonalds food is popular.

Not to mention Presidential elections in a certain nation....... BC -- Why do people order double cheeseburgers, large French fries, and Diet Coke? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le lundi 02 avril 2012 à 09:08 +0200, Vincent Untz a écrit :

Hi Robert,

Le samedi 31 mars 2012, à 01:40 +0200, Robert Kaiser a écrit :

...

Brian K. White schrieb:

...

Run all software under a debugger all the time in live production just to satisfy your lack of clue? No.

Exactly, not needed. What is nice though is to collect crash reports from optimized builds (with a default-activated but opt-in-with-dialog model), collect that data and take action on the issues that rank high in the statistics coming out of that.

This is what we are doing at Mozilla, and I'm sure we'd be willing to help others who want to deploy the Free Software tools Breakpad (client-side) and Socorro (server-side) that we are using for that purpose.

Just wondering: do you know why Fedora went with ABRT instead of re-using what Mozilla had developped? And do you have any opinion on ABRT?

IIRC, Mozilla stuff (based on google minidump) was not available for x86-64 for a long time. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 4/1/2012 12:41 PM, Graham Anderson wrote:

On Saturday 31 Mar 2012 01:05:05 Brian K. White wrote:

...

On 3/30/2012 8:04 PM, Cristian Rodríguez wrote:

...

Well, let see who's proposal succeeds and gets implemented.

Popularity in no way implies quality. McDonalds food is popular.

And he who shouts the loudest doesn't always make the most salient points.

...

From my point of view I can distill your argument down to a single point of view "don't change things because it's different".

Exactly. If there are any consequences to a change, then have a reason to change other than merely because it is different or merely because it is new or merely because someone else is doing it. The value in the change must outweigh the consequences of it. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, April 03, 2012 13:19:33 Ludwig Nussel wrote:

Andreas Jaeger wrote:

...

On 03/30/2012 11:04 AM, Ludwig Nussel wrote:

...

Cristian Rodríguez wrote:

...

- For users, implement what Lnussel and fcrozat suggested, a separate tmp per user in /run/<user>/ tmpfs. Otherwise temporary file creation bugs will keep biting us forever.

I'm in favor of a per user $TMPDIR. I didn't say I like having it in /run/ ie tmpfs. tmpfs of course has the advantage of avoiding fragile and racy cleanup operations, at least on systems with short uptimes. In fact I use tmpfs myself for /tmp on my EEE PC with SSD. I don't use that system for any serious work though. I doubt it is a good idea for a general purpose installation to put TMPDIR on tmpfs. So I'd rather like to see TMPDIR per user, on persistent storage. The exact location would be the next controversial subject then though I guess :-)

I blogged about this thread: http://jaegerandi.blogspot.de/2012/03/tmp-as-tmpfs-for-opensuse.html

Lennart commented on my post with two points - one adressing your point above and the other that it's easy to revert the default:

"AJ, if you want private /tmp directories for users, I'd suggest to use kernel namespaces for that (there's a PAM module for that), instead of relying on $TMPDIR. This might break a few things which expect that /tmp is shared though, but is more comprehensive and secure, and leaves $TMPDIR to the admin and user (Which I think is a good thing). It also mimics more closely what we do for services with PrivateTmp=yes.

Well, for services this may make sense but for user sessions the namespace for /tmp doesn't answer the question whether to use tmpfs or if not where to store the local tmp. Also a namespace on /tmp would permanently hide the real /tmp from the user, right?

Yes, it would hide it, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 03/04/12 10:38, Claudio Freire escribió:

Aside from that, the namespace solution is really nice. Secure, elegant. I like it.

Yes, I believe this is the only reasonable way to go, it _has_ to be something that can be enforced at kernel level and forces userspace to behave ;-) Cheers. ! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Apr 03, 2012 at 09:09:47PM -0300, Cristian Rodríguez wrote:

El 30/03/12 14:33, Per Jessen escribió:

...

Richard Guenther wrote:

...

On Fri, 30 Mar 2012, Karl Eichwalder wrote:

Instead of noting that TMP_DIRS_TO_CLEAR is ignored we should remove those now pointless variables (given that for 12.2 systemd will be mandatory?)

I believe you can answer your question by yourself now.. see:

http://lwn.net/Articles/490413/

Huh? The binaries resulting from the merge are still separate, this just allows the duplicated code to be merged together in one tree, there should not be any change due to this at all. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org