[opensuse-project] crashdb?
Hi, http://crashdb.opensuse.org/ only returns 404. Is that a permanent condition due to lack of maintainer or are there plans to get it up again? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Am Freitag, 4. Februar 2011 schrieb Ludwig Nussel:
Hi,
http://crashdb.opensuse.org/ only returns 404. Is that a permanent condition due to lack of maintainer or are there plans to get it up again?
I put quite some effort into reviving it during hackweek V and then gave up on it completely as the 11.3+ kernel will not call apport if the ulimit is set to 0. As such there won't be any reports for crashdb - leave alone retraces. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le lundi 07 février 2011 à 12:26 +0100, Stephan Kulow a écrit :
Am Freitag, 4. Februar 2011 schrieb Ludwig Nussel:
Hi,
http://crashdb.opensuse.org/ only returns 404. Is that a permanent condition due to lack of maintainer or are there plans to get it up again?
I put quite some effort into reviving it during hackweek V and then gave up on it completely as the 11.3+ kernel will not call apport if the ulimit is set to 0. As such there won't be any reports for crashdb - leave alone retraces.
One workaround could be to unset ulimit from apport ( or fedora
alternative, abrt) package, by dropping a file in /etc/profile.d
--
Frederic Crozat
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 12:26 +0100, Stephan Kulow a écrit :
Am Freitag, 4. Februar 2011 schrieb Ludwig Nussel:
Hi,
http://crashdb.opensuse.org/ only returns 404. Is that a permanent condition due to lack of maintainer or are there plans to get it up again?
I put quite some effort into reviving it during hackweek V and then gave up on it completely as the 11.3+ kernel will not call apport if the ulimit is set to 0. As such there won't be any reports for crashdb - leave alone retraces.
One workaround could be to unset ulimit from apport ( or fedora alternative, abrt) package, by dropping a file in /etc/profile.d
Yeah, maintaining apport package is yet another topic. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le lundi 07 février 2011 à 13:42 +0100, Stephan Kulow a écrit :
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 12:26 +0100, Stephan Kulow a écrit :
Am Freitag, 4. Februar 2011 schrieb Ludwig Nussel:
Hi,
http://crashdb.opensuse.org/ only returns 404. Is that a permanent condition due to lack of maintainer or are there plans to get it up again?
I put quite some effort into reviving it during hackweek V and then gave up on it completely as the 11.3+ kernel will not call apport if the ulimit is set to 0. As such there won't be any reports for crashdb - leave alone retraces.
One workaround could be to unset ulimit from apport ( or fedora alternative, abrt) package, by dropping a file in /etc/profile.d
Yeah, maintaining apport package is yet another topic.
Well, I'd suggest switching to abrt, which does the stacktrace
decyphering on the client side and can be simply plugged on bugzilla.
--
Frederic Crozat
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 13:42 +0100, Stephan Kulow a écrit :
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 12:26 +0100, Stephan Kulow a écrit :
Am Freitag, 4. Februar 2011 schrieb Ludwig Nussel:
Hi,
http://crashdb.opensuse.org/ only returns 404. Is that a permanent condition due to lack of maintainer or are there plans to get it up again?
I put quite some effort into reviving it during hackweek V and then gave up on it completely as the 11.3+ kernel will not call apport if the ulimit is set to 0. As such there won't be any reports for crashdb - leave alone retraces.
One workaround could be to unset ulimit from apport ( or fedora alternative, abrt) package, by dropping a file in /etc/profile.d
Yeah, maintaining apport package is yet another topic.
Well, I'd suggest switching to abrt, which does the stacktrace decyphering on the client side and can be simply plugged on bugzilla.
Well, the point behind crashdb and the retracer was that the client doesn't need the debuginfos installed. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le lundi 07 février 2011 à 14:17 +0100, Stephan Kulow a écrit :
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 13:42 +0100, Stephan Kulow a écrit :
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 12:26 +0100, Stephan Kulow a écrit :
Am Freitag, 4. Februar 2011 schrieb Ludwig Nussel:
Hi,
http://crashdb.opensuse.org/ only returns 404. Is that a permanent condition due to lack of maintainer or are there plans to get it up again?
I put quite some effort into reviving it during hackweek V and then gave up on it completely as the 11.3+ kernel will not call apport if the ulimit is set to 0. As such there won't be any reports for crashdb - leave alone retraces.
One workaround could be to unset ulimit from apport ( or fedora alternative, abrt) package, by dropping a file in /etc/profile.d
Yeah, maintaining apport package is yet another topic.
Well, I'd suggest switching to abrt, which does the stacktrace decyphering on the client side and can be simply plugged on bugzilla.
Well, the point behind crashdb and the retracer was that the client doesn't need the debuginfos installed.
Indeed, but abrt is able to download them on demand and install them in
a temporary chroot just for "decyphering".
So, one less server to maintain for us ;)
--
Frederic Crozat
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 14:17 +0100, Stephan Kulow a écrit :
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 13:42 +0100, Stephan Kulow a écrit :
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 12:26 +0100, Stephan Kulow a écrit :
Am Freitag, 4. Februar 2011 schrieb Ludwig Nussel: > Hi, > > http://crashdb.opensuse.org/ only returns 404. Is that a > permanent condition due to lack of maintainer or are there > plans to get it up again?
I put quite some effort into reviving it during hackweek V and then gave up on it completely as the 11.3+ kernel will not call apport if the ulimit is set to 0. As such there won't be any reports for crashdb - leave alone retraces.
One workaround could be to unset ulimit from apport ( or fedora alternative, abrt) package, by dropping a file in /etc/profile.d
Yeah, maintaining apport package is yet another topic.
Well, I'd suggest switching to abrt, which does the stacktrace decyphering on the client side and can be simply plugged on bugzilla.
Well, the point behind crashdb and the retracer was that the client doesn't need the debuginfos installed.
Indeed, but abrt is able to download them on demand and install them in a temporary chroot just for "decyphering".
So, one less server to maintain for us ;)
Even worse. Noone will approve downloading 700MB for a crash report. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le lundi 07 février 2011 à 14:31 +0100, Stephan Kulow a écrit :
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 14:17 +0100, Stephan Kulow a écrit :
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 13:42 +0100, Stephan Kulow a écrit :
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
Le lundi 07 février 2011 à 12:26 +0100, Stephan Kulow a écrit : > Am Freitag, 4. Februar 2011 schrieb Ludwig Nussel: > > Hi, > > > > http://crashdb.opensuse.org/ only returns 404. Is that a > > permanent condition due to lack of maintainer or are there > > plans to get it up again? > > I put quite some effort into reviving it during hackweek V and > then gave up on it completely as the 11.3+ kernel will not call > apport if the ulimit is set to 0. As such there won't be any > reports for crashdb - leave alone retraces.
One workaround could be to unset ulimit from apport ( or fedora alternative, abrt) package, by dropping a file in /etc/profile.d
Yeah, maintaining apport package is yet another topic.
Well, I'd suggest switching to abrt, which does the stacktrace decyphering on the client side and can be simply plugged on bugzilla.
Well, the point behind crashdb and the retracer was that the client doesn't need the debuginfos installed.
Indeed, but abrt is able to download them on demand and install them in a temporary chroot just for "decyphering".
So, one less server to maintain for us ;)
Even worse. Noone will approve downloading 700MB for a crash report.
Well, if it is cached, I'm not sure (and with debuginfo, we don't have
to download the full source).
It is a tradeoff : either you centralize this, which requires
maintenance but low bandwith, or you decentralize at the cost of
bandwith.
..
I've double-checked Abrt website and since the last time I looked at
Abrt when I was packaging it for Mdv, a retrace server is being
developped for F15, so you can get either "local" backtrace generation
or "remote" : https://fedorahosted.org/abrt/wiki/AbrtRetraceServer
--
Frederic Crozat
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
I've double-checked Abrt website and since the last time I looked at Abrt when I was packaging it for Mdv, a retrace server is being developped for F15, so you can get either "local" backtrace generation or "remote" : https://fedorahosted.org/abrt/wiki/AbrtRetraceServer Well, you're free to do what you like - we never used apport for openSUSE, so it would be a first anyway. It has been around for a while, but never was default or promoted outside developer meetings.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le lundi 07 février 2011 à 16:24 +0100, Stephan Kulow a écrit :
Am Montag, 7. Februar 2011 schrieb Frederic Crozat:
I've double-checked Abrt website and since the last time I looked at Abrt when I was packaging it for Mdv, a retrace server is being developped for F15, so you can get either "local" backtrace generation or "remote" : https://fedorahosted.org/abrt/wiki/AbrtRetraceServer Well, you're free to do what you like - we never used apport for openSUSE, so it would be a first anyway. It has been around for a while, but never was default or promoted outside developer meetings.
I guess I'll add it on my todo list, not sure when it could make it
happen thought :(
--
Frederic Crozat
Dne 7.2.2011 12:26, Stephan Kulow napsal(a):
Am Freitag, 4. Februar 2011 schrieb Ludwig Nussel:
Hi,
http://crashdb.opensuse.org/ only returns 404. Is that a permanent condition due to lack of maintainer or are there plans to get it up again?
I put quite some effort into reviving it during hackweek V and then gave up on it completely as the 11.3+ kernel will not call apport if the ulimit is set to 0. As such there won't be any reports for crashdb - leave alone retraces.
That is why we set ulimit globally to 1 in SLE 11. The logic behind the kernel change was that an infinite loop can happen if a crash handler itself crashes, and decoding such process loops is too difficult for kernel. So ulimit 0 means "do not run crash handler" and crash handlers are supposed to set this for themselves and their children. Global ulimit 1 means that core dumps still won't be produced (i don't recall what units ulimit uses, but no core dump will ever fit under 1kB anyway), but crash handlers will be activated. m. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (4)
-
Frederic Crozat -
Jan Matejek -
Ludwig Nussel -
Stephan Kulow