[opensuse-factory] to tmp-on-tmpfs or not tmp-on-tmpfs
I'd like to make a summary of the discussion (and add my thoughts, I've been running with my /tmp in tmpfs on several systems for years). 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. Limiting the size like Debian does (max 50% of ram for all tmpfs'es) is a posibility, but then it gets full. And then? Random crashes, apps refusing to start, horrible slow performance due to memory running full. Can we add swap? That is slow. Not just that, by the time the OOM killer finally decides to kill something in your trashing system, it has been frozen for an hour if you're lucky. Besides, if it fills up swap you can't hibernate anymore. So downside of tmp on tmpfs: we introduce the notion of "have you tried turning it on and off again?" that MS is just about to do away with (or so they claim). Upside of this feature (from Fedora page): a few saved hard disk cycles and theoretical power savings, most likely quickly outdone by the increased swap usage. Oh, and we get closer to Solaris, which has been doing this forever. Yay. The verdict is simple: we can't follow upstream in this or other distro's in this. It doesn't work for us. Debian wants to build an OS for systemadmins. They have to tweak the system for their usecase anyway. And this is fine for servers, I bet. Fedora wants people to test the latest and greatest Linux has to offer. Their users are not supposed to run a desktop/laptop system for a month without upgrading to new unstable things and rebooting. But openSUSE wants to build an OS for people who need to get work done, not fiddle with system internals if they don't have to. Graphics designers, netbook owners, VM-users, DVD-burning users, flash-users, pdf-viewing people, web-browsing-users - they all can't work with this... I think we should pick a sensible default: put stuff which doesn't have to be in memory, on the disk. Keep the system performant for common usecases. Those who want their /tmp on tmpfs can use fstab. If, on one sunny day, the world has been turned around and all apps clean up after themselves or abuse /var/tmp for the data which wasn't supposed to be kept over boot (or, in an extremely green/pink world, use the proper locations like mentioned in Lennarts' blog on this subject), we can re- consider. And maybe we find other solutions to the problems mentioned - like cleaning up /tmp once it is getting full or stuff like that. But for now - 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.
+1 -- ____________ Steven L Hess ARS KC6KGE DM05gd22 Skype user flamebait Cell 661 487 0357 (Facetime) Google Voice 661 769 6201 openSUSE Linux 12.1 -- 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 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
On Wed, Mar 28, 2012 at 11:47 PM, Peter Linnell <mrdocs@opensuse.org> wrote:
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
Le mercredi 28 mars 2012, à 21:10 +0200, Jos Poortvliet a écrit :
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. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- 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
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
Le jeudi 29 mars 2012 à 08:01 +0200, Vincent Untz a écrit :
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).
Also, by default, we clean files in /tmp that are older than 10 days. It might help with the switch to tmpfs.
Yes. -- Frederic Crozat <fcrozat@suse.com> SUSE -- 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:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-29 11:21, Ruediger Meier wrote:
Not if your uptime is bigger than 10 days. - -- 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/ iEYEARECAAYFAk90LxkACgkQIvFNjefEBxpcHACdGNMKja0NH7SdwpgYFvbZkANY n6gAoJhCgrYxMunZATws+8BBNi9XjBLY =iej4 -----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, Carlos E. R. wrote:
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:
+1. Btw, see https://features.opensuse.org/309448 -- Per Jessen, Zürich (16.6°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ruediger Meier wrote:
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
Ruediger Meier <sweet_f_a@gmx.de> writes:
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
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?) Richard. -- Richard Guenther <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Richard Guenther <rguenther@suse.de> writes:
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
Le vendredi 30 mars 2012 à 15:19 +0200, Karl Eichwalder a écrit :
Please don't. There is no point in duplicating such a bug. I'd prefer people to help on fixing it instead. When/If it will be fixed for 12.1, it will be also fixed for 12.2. -- Frederic Crozat <fcrozat@suse.com> SUSE -- 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 2012-03-30 19:33, Per Jessen wrote:
I thought it was not going to happen for 12.2 - -- 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/ iEYEARECAAYFAk919ScACgkQIvFNjefEBxp+CwCghFFMKV7sdgJgogFGajJDOxQQ sjQAn28X61C9B5R6Vpr67ayA3/bbiqKv =tT3T -----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 14:33, Per Jessen escribió:
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
Cristian Rodríguez wrote:
Sorry about hijacking the thread, but it seems to me to be an important comment by Richard (of SUSE Labs). Perhaps it's better to keep it [sysvinit] until it has become largely unusable due to lack of maintenance? 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. -- Per Jessen, Zürich (10.9°C) -- 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.
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
El 30/03/12 14:33, Per Jessen escribió:
I believe you can answer your question by yourself now.. see: http://lwn.net/Articles/490413/ -- 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:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2012-03-30 at 13:53 +0200, Karl Eichwalder wrote:
Sidenote Which I and others have reported previously. In fact, I do not know where to find the up to date release notes. http://en.opensuse.org/openSUSE:Release_Notes --> http://www.suse.com/releasenotes/i386/openSUSE/12.1/RELEASE-NOTES.en.html - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk91qsIACgkQtTMYHG2NR9WKAACeNtFnBHun5DfEKFN0C95wE6u3 PyMAnjNqMOlYwu7aR5KLArIhJJHLYjOG =3era -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
"Carlos E. R." <carlos.e.r@opensuse.org> writes:
For viewing the release notes online, that's probably the right location. Maybe, the automatic update process is currently broken (because of the move from novell.com to suse.com?). We must check it. The most recent document it available in SVN, which is linked from http://en.opensuse.org/openSUSE:Release_Notes.
-- 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
Karl Eichwalder wrote:
http://www.suse.com/releasenotes/i386/openSUSE/12.1/RELEASE-NOTES.en.html
is outdated):
See also https://bugzilla.novell.com/show_bug.cgi?id=750780 -- Per Jessen, Zürich (14.6°C) -- 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 08:01:32 Vincent Untz wrote:
True, we should fix things. But as Ruediger said, we have to watch peaks, not the average state. My current tmp is only 512 K (I did some cleaning up yesterday).
Also, by default, we clean files in /tmp that are older than 10 days. It might help with the switch to tmpfs.
That is imho a very sensible thing to do, yes. And will probably help. Again, I suggest to let Fedora, Debian and others figure out what bugs this causes - and subject our users to it in another 8 or 16 months :D
Cheers,
Vincent
On Thursday 29 Mar 2012 08:01:32 Vincent Untz wrote:
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
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. - 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. - Fix buggy software if any. Cheers. -- 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:
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 <aj@suse.com> 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, 2012-03-29 at 17:30 +0200, Andreas Jaeger wrote: ...
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
On Thu, Mar 29, 2012 at 10:21 AM, Cristian Rodríguez <crrodriguez@opensuse.org> 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.
I like this. I already use a tmpdir located in /home/<me>/tmp, managed by way of TMPDIR. -- 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 12:31, Jon Nelson escribió:
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. -- 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 <klaussfreire@gmail.com> wrote:
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
On Thu, Mar 29, 2012 at 1:37 PM, Jon Nelson <jnelson-suse@jamponi.net> wrote:
Arguable... but ok, I'll accept your point, it should be easily changeable to be able to easily debug services. -- 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ó:
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
On Thursday 29 of March 2012 14:45EN, Cristian Rodríguez wrote:
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. Michal Kubeček -- 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 :
I think this demonstrate the need to setup abrt support for openSUSE to be able to collect crash traces as they appear. -- Frederic Crozat <fcrozat@suse.com> SUSE -- 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:
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-----
On 3/29/2012 1:45 PM, Cristian Rodríguez wrote:
Run all software under a debugger all the time in live production just to satisfy your lack of clue? No. Most software actually runs fine for months and then only rarely and unpredictably fails once. You can't retroactively run it in a debugger to examine that crash. You can't know that today it will crash so start it in the debugger. Maybe you can't start it in anythng today because it's long-running daemon software that takes 6 months continuous running just to get to the point where it might or might not crash. Or the system as a whole might have crashed due to hardware or admin screw-up and not necessarily because any any of the software crashed, and yet the temp files left behind would be just as desirable. Maybe a big file tickles a bad spot of ram, maybe a file with certain patterns in it causes ram or some other hardware to fail. Maybe the temporary webcam jpg shows the cleaning lady kicking the cord or plugging in the power-hungry vacuum into the ups. Maybe a large data-manipulation job could be resumed instead of started over saving unknown time and money for some business... 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. 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. It's a generic unix(like) base for _anything_. Old software, new software, software written by experts and idiots, closed source commercial software that is business critical and not optional, software that works on huge files, or huge numbers of small files, 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. It's not personal, my own and everyone else's individual personal direct experience, by itself, is also a corner case that doesn't matter. -- bkw -- 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 2012-03-31 00:34, Brian K. White wrote:
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
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. Robert Kaiser "Crash Scene Investigator" at Mozilla -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Robert, Le samedi 31 mars 2012, à 01:40 +0200, Robert Kaiser a écrit :
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? Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- 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 :
IIRC, Mozilla stuff (based on google minidump) was not available for x86-64 for a long time. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Vincent Untz schrieb:
Unfortunately, I don't know the answer to that. I know that some people at RedHat at least are very interested in how they could use Breakpad/Socorro. I don't really know ABRT and have little knowledge about Fedora so I can't reasonably compare or give statements about what they decide or about the tool itself. Robert Kaiser -- 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
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.
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 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. -- bkw -- 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:
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 31/03/12 16:05, Brian K. White wrote:
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
On Fri, 2012-03-30 at 18:34 -0400, Brian K. White wrote: <trim>
<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 Thu, Mar 29, 2012 at 12:21 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
My point of decreased performance is not a corner case, it can be measured. If tmpfs is used, I'd recommend it be capped at below 10% of total system RAM and, in that case, it would probably swap under pressure and seriously decrease system performance. But...
I totally agree.
And here too, in principle, but there are numerous issues to account for here, including firefox's tendency to put downloads in tmp-dir. If FF picks up this /run/<user> location, we're basically in the same situation as putting /tmp on tmpfs.
- Fix buggy software if any.
Can't argue against that. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 29 Mar 2012, Claudio Freire wrote:
Still nobody had a suggestion where to put large short-living data. Like GCC wants to do. Currently it uses TMPDIR, if that ends up being tmpfs it won't work (and no, out-of-disk-space situations are _not_ easy to handle, these are temporary files that are shared across processes). So, what's the location one should use instead (or rather, try first)? From GCCs documentation: @item TMPDIR @findex TMPDIR If @env{TMPDIR} is set, it specifies the directory to use for temporary files. GCC uses temporary files to hold the output of one stage of compilation which is to be used as input to the next stage: for example, the output of the preprocessor, which is the input to the compiler proper. Richard.
Cristian Rodríguez wrote:
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 :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, 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:
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
-----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? :-? - -- 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/ iEYEARECAAYFAk91yTwACgkQIvFNjefEBxrcTgCeNFRf6TnaGLoB/RWFNI9pnQp7 KtkAoJHDe3qD/7Zr/9s5v5nPj5Q55UJu =FQLu -----END PGP SIGNATURE----- -- 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 <aj@suse.com> 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
Andreas Jaeger wrote:
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? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, 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 Tuesday, April 03, 2012 13:19:33 Ludwig Nussel wrote:
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
On Tue, Apr 3, 2012 at 8:31 AM, Andreas Jaeger <aj@suse.com> wrote:
IIRC, but I've made mistakes here, there's no way to associate something to more than one namespace. At least that's true with network namespaces. That would make it difficult for "shared files" or preexisting files in /tmp. Aside from that, the namespace solution is really nice. Secure, elegant. I like it. -- 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
+1 -- ____________ Steven L Hess ARS KC6KGE DM05gd22 Skype user flamebait Cell 661 487 0357 (Facetime) Google Voice 661 769 6201 openSUSE Linux 12.1 -- 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 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
On Wed, Mar 28, 2012 at 11:47 PM, Peter Linnell <mrdocs@opensuse.org> wrote:
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
Le mercredi 28 mars 2012, à 21:10 +0200, Jos Poortvliet a écrit :
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. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (26)
-
Andreas Jaeger -
Basil Chupin -
Boris Manojlovic -
Brian K. White -
Carlos E. R. -
Carlos E. R. -
Claudio Freire -
Cristian Rodríguez -
Frederic Crozat -
Graham Anderson -
Greg KH -
Hans Witvliet -
Jon Nelson -
Jos Poortvliet -
Karl Eichwalder -
Lars Müller -
Ludwig Nussel -
Michal Kubeček -
Per Jessen -
Peter Linnell -
Ralf Lang -
Richard Guenther -
Robert Kaiser -
Ruediger Meier -
Steven Hess -
Vincent Untz