Rodney Baker wrote:
On Thu, 31 Jan 2013 15:23:24 Per Jessen wrote:
[...]
When a problem is not immediately reproducable, you can't do much else than wait and see - collect diagnostics, core dumps etc. Debugging a production issue with gdb and strace is for the optimistic.
What? It isn't opportunistic at all.
I meant it is optimistic to expect to have access to a production system and to run e.g. a daemon with gdb or strace it.
I would agree. It would be silly to try that on a live, production system, which is why, if you must do the debugging yourself, you need test environment where you can duplicate the production system (including simulating the problem transaction(s)), do the debugging and test the fixes before pushing them out into the production environment.
As anyone who has been around for long enough will know, it is impossible to completely duplicate a production system. An imitation is usually as good as it gets. When this doesn't work to your or your customer's satisfaction, you have to collect diagnostics as and when they appear. Which might just be files left in /tmp. Of course, daemons which might leave useful diagnostics in /tmp will have to be rewritten.
Of course, this requires considerable investment in the initial instance but it isn't really optional if you are developing and/or maintaining software in- house (but this is getting outside the scope of the original discussion).
Both very true. -- Per Jessen, Zürich (3.5°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org