On 3/29/2012 1:45 PM, Cristian Rodríguez wrote:
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...
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