9:03 a.m.
Immediate planned work:
* Deployment doc: prepare unsuspecting vict^W^W user/admin
who installs and uses abrt for the first time what to expect.
It needs to answer user-centric information about "How Do I Do X?
How Do I Do Y?". Example doc for yum:
http://dsilas.fedorapeople.org/deployment-guide/latest/Yum.html
Douglas Silas <dhensley(a)redhat.com> may help with review
* Design doc needs updating/consolidating:
doc/DESIGN and https://fedorahosted.org/abrt/wiki/AbrtArchitecture
* Identify list of known critical bugs/badly needed features for RHEL6,
email it to Radek.
* ccpp hook should fall back to analyzing coredump
if /proc/PID/exe is not readable.
* ongoing work in determining why X crashes on jmoskovc machine
produce truncated coredumps.
* Make "Enabled = yes" to work in per-plugin .conf files.
* Discuss auto-dlopening of plugins.
* New directive in CCpp.conf:
DebugInfoDir = /path/to/debuginfos:/path/to/debuginfos2:...
this in effect adds DebuginfoFS functionality to abrt
* Put text files _also_ in BZ comment field if they are small
(currently they are always attached).
* Add version info to "abrt X.Y.Z detected a crash" BZ comment.
* Add [Cancel] button to "Do you really want to send <something>?"
dialog box.
Please reply to this email when you committed to git
a change which fulfills one of the points above.
--
vda
11:32 a.m.
On Wed, 2009-11-18 at 16:03 +0100, Denys Vlasenko wrote:
Immediate planned work:
...
* New directive in CCpp.conf:
DebugInfoDir = /path/to/debuginfos:/path/to/debuginfos2:...
this in effect adds DebuginfoFS functionality to abrt
Implemented it as "ReadonlyLocalDebugInfoDirs" directive.
"Readonly" added to make it more obvious that files are
only ever read from there. "Local" because we might want
to implement, say,
RemoteDebugInfos = http://a.server/path
later.
--
vda
5:29 a.m.
On 11/18/2009 04:03 PM, Denys Vlasenko wrote:
Immediate planned work:
* Discuss auto-dlopening of plugins.
I don't like this, because how would user disable the plugin? If he
didn't want to use it? I know it shouldn't be mentioned in config file
then, but still, if I don't want to have this enabled, it shouldn't
enable it self automatically.
* Add [Cancel] button to "Do you really want to
send<something>?"
dialog box.
Fixed
* ongoing work in determining why X crashes on jmoskovc machine
produce truncated coredumps.
should be fixed in kernel 2.6.32 see
http://www.linuxhq.com/kernel/v2.6/32-rc4/fs/exec.c (search for
wait_for_dump_helpers()). I'm just downloading the rpm from koji, so
let's hope it won't destroy my laptop :)
Please reply to this email when you committed to git
a change which fulfills one of the points above.
--
vda
5:50 a.m.
New subject: [Crash-catcher] ABRT: FYI - FileTransfer plugin and libtar
hello,
some of my testing involved FileTransfer plugin and I found out, that some
recent downgr^Wupgrade of libtar crashes instead of creating tar archive
I filed a high-priority bug in Bugzilla for this:
https://bugzilla.redhat.com/show_bug.cgi?id=538770
in the meanwhile, if you wish to use the FileTransfer plugin,
use .zip as the file format, as it's the only one that
does not need libtar.
Hope the libtar maintainer reacts quickly...
Daniel Novotny
7:34 a.m.
New subject: [Crash-catcher] auto-dlopening of plugins
On Thu, 2009-11-19 at 12:29 +0100, Jiri Moskovcak wrote:
On 11/18/2009 04:03 PM, Denys Vlasenko wrote:
> Immediate planned work:
>
> * Discuss auto-dlopening of plugins.
>
I don't like this, because how would user disable the plugin? If he
didn't want to use it? I know it shouldn't be mentioned in config file
then, but still, if I don't want to have this enabled, it shouldn't
enable it self automatically.
The though occurred to me when I was testing RunApp plugin
for inclusion of Xorg.0.log for X crashes.
I modified the abrt.conf by adding ActionsAndReporters = RunApp(...):
# Common abrt settings
[ Common ]
# With this option set to "yes",
# only crashes in signed packages will be analyzed.
OpenGPGCheck = no
# GPG keys
OpenGPGPublicKeys = /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
# Blacklisted packages
BlackList = nspluginwrapper
# Enabled plugins. There has to be exactly one database plugin
EnabledPlugins = SQLite3, CCpp, Logger, Kerneloops, KerneloopsScanner, KerneloopsReporter,
Bugzilla, Python
# Database
Database = SQLite3
# Max size for crash storage [MiB]
MaxCrashReportsSize = 1000
# Vector of actions and reporters which are activated immediately after a crash occurs
ActionsAndReporters = RunApp("test x`cat component` = xxorg-x11-server-Xorg
&& cp /var/log/Xorg.0.log .")
run tested it - BUMMER! "RunApp plugin is not loaded"!
Yep, I need to add it to EnabledPlugins.
I am afraid a lot of users will bitch "wtf, can't this damn
program understand that if I said ActionsAndReporters = abc,
them obviously abc plugin should be loaded?"
And they are right - abrt can figure it out.
It can be easily done without resorting to scanning every .conf
directive for plugin names: instead, we can teach GetAction(pluginName),
GetReporter() et al. to try to load the plugin if it is not loaded yet,
and complain only when load attempt fails.
Currently, it errors out with "Plugin '%s' is not registered"
if plugin is not registered. It may well just register it, and continue.
This way, EnabledPlugins = ... directive will mean "load these plugins
right at the start" - because some of them, like ccpp, do important
initialization. And pludins which do not have important things to do
at initialization won't need to be listed there.
Actually, now that I looked at the code, I have a tangential question -
why we load *all* plugins, then *register* only some of them? This means
unused plugins still take up some memory, right? Why do we need two
different concepts of "loaded" and "registered"? One might be
enough...
--
vda
8:24 a.m.
New subject: [Crash-catcher] auto-dlopening of plugins
On 11/19/2009 02:34 PM, Denys Vlasenko wrote:
On Thu, 2009-11-19 at 12:29 +0100, Jiri Moskovcak wrote:
> On 11/18/2009 04:03 PM, Denys Vlasenko wrote:
>> Immediate planned work:
>>
>> * Discuss auto-dlopening of plugins.
>>
>
> I don't like this, because how would user disable the plugin? If he
> didn't want to use it? I know it shouldn't be mentioned in config file
> then, but still, if I don't want to have this enabled, it shouldn't
> enable it self automatically.
The though occurred to me when I was testing RunApp plugin
for inclusion of Xorg.0.log for X crashes.
I modified the abrt.conf by adding ActionsAndReporters = RunApp(...):
# Common abrt settings
[ Common ]
# With this option set to "yes",
# only crashes in signed packages will be analyzed.
OpenGPGCheck = no
# GPG keys
OpenGPGPublicKeys = /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
# Blacklisted packages
BlackList = nspluginwrapper
# Enabled plugins. There has to be exactly one database plugin
EnabledPlugins = SQLite3, CCpp, Logger, Kerneloops, KerneloopsScanner,
KerneloopsReporter, Bugzilla, Python
# Database
Database = SQLite3
# Max size for crash storage [MiB]
MaxCrashReportsSize = 1000
# Vector of actions and reporters which are activated immediately after a crash occurs
ActionsAndReporters = RunApp("test x`cat component` =
xxorg-x11-server-Xorg&& cp /var/log/Xorg.0.log .")
run tested it - BUMMER! "RunApp plugin is not loaded"!
Yep, I need to add it to EnabledPlugins.
I am afraid a lot of users will bitch "wtf, can't this damn
program understand that if I said ActionsAndReporters = abc,
them obviously abc plugin should be loaded?"
And they are right - abrt can figure it out.
It can be easily done without resorting to scanning every .conf
directive for plugin names: instead, we can teach GetAction(pluginName),
GetReporter() et al. to try to load the plugin if it is not loaded yet,
and complain only when load attempt fails.
Currently, it errors out with "Plugin '%s' is not registered"
if plugin is not registered. It may well just register it, and continue.
This way, EnabledPlugins = ... directive will mean "load these plugins
right at the start" - because some of them, like ccpp, do important
initialization. And pludins which do not have important things to do
at initialization won't need to be listed there.
Ok, I agree here, that action plugins (and reporters as they are
required by some analyzers??) may be enabled on demand without being
listed in config file explicitly, so user doesn't even have to know that
the "action" is done by some plugin. But I think it would be great to do
some more surgery into abrt.conf e.g. move analyzer - reporter
association from abrt.conf to per plugin conf.
Actually, now that I looked at the code, I have a tangential question -
why we load *all* plugins, then *register* only some of them? This means
unused plugins still take up some memory, right? Why do we need two
different concepts of "loaded" and "registered"? One might be
enough...
1. load all plugins to determine which plugins do we have (as we can't
trust the config file :))
2. enable (run init() at least I hope it works that way) only those
plugins we want (listed in conf file)
So what is the proposal here? To load and enable all installed plugins?
--
vda
8:44 a.m.
New subject: [Crash-catcher] auto-dlopening of plugins
On Thu, 2009-11-19 at 15:24 +0100, Jiri Moskovcak wrote:
> run tested it - BUMMER! "RunApp plugin is not
loaded"!
>
> Yep, I need to add it to EnabledPlugins.
>
> I am afraid a lot of users will bitch "wtf, can't this damn
> program understand that if I said ActionsAndReporters = abc,
> them obviously abc plugin should be loaded?"
>
> And they are right - abrt can figure it out.
>
> It can be easily done without resorting to scanning every .conf
> directive for plugin names: instead, we can teach GetAction(pluginName),
> GetReporter() et al. to try to load the plugin if it is not loaded yet,
> and complain only when load attempt fails.
>
> Currently, it errors out with "Plugin '%s' is not registered"
> if plugin is not registered. It may well just register it, and continue.
>
> This way, EnabledPlugins = ... directive will mean "load these plugins
> right at the start" - because some of them, like ccpp, do important
> initialization. And pludins which do not have important things to do
> at initialization won't need to be listed there.
>
Ok, I agree here, that action plugins (and reporters as they are
required by some analyzers??) may be enabled on demand without being
listed in config file explicitly, so user doesn't even have to know that
the "action" is done by some plugin. But I think it would be great to do
some more surgery into abrt.conf e.g. move analyzer - reporter
association from abrt.conf to per plugin conf.
>
> Actually, now that I looked at the code, I have a tangential question -
> why we load *all* plugins, then *register* only some of them? This means
> unused plugins still take up some memory, right? Why do we need two
> different concepts of "loaded" and "registered"? One might be
enough...
>
1. load all plugins to determine which plugins do we have (as we can't
trust the config file :))
2. enable (run init() at least I hope it works that way) only those
plugins we want (listed in conf file)
So what is the proposal here? To load and enable all installed plugins?
Load and enable all plugins mentioned on 'EnabledPlugins = ...' line.
Then, if while executing any other directive we see a plugin
which is not loaded, load and enable it.
In C++ terms, "we see" means "GetAction(pluginName),
GetReporter(pluginName), etc are called"
--
vda
6:28 a.m.
New subject: [Crash-catcher] auto-dlopening of plugins
On 11/19/2009 03:44 PM, Denys Vlasenko wrote:
On Thu, 2009-11-19 at 15:24 +0100, Jiri Moskovcak wrote:
>> run tested it - BUMMER! "RunApp plugin is not loaded"!
>>
>> Yep, I need to add it to EnabledPlugins.
>>
>> I am afraid a lot of users will bitch "wtf, can't this damn
>> program understand that if I said ActionsAndReporters = abc,
>> them obviously abc plugin should be loaded?"
>>
>> And they are right - abrt can figure it out.
>>
>> It can be easily done without resorting to scanning every .conf
>> directive for plugin names: instead, we can teach GetAction(pluginName),
>> GetReporter() et al. to try to load the plugin if it is not loaded yet,
>> and complain only when load attempt fails.
>>
>> Currently, it errors out with "Plugin '%s' is not registered"
>> if plugin is not registered. It may well just register it, and continue.
>>
>> This way, EnabledPlugins = ... directive will mean "load these plugins
>> right at the start" - because some of them, like ccpp, do important
>> initialization. And pludins which do not have important things to do
>> at initialization won't need to be listed there.
>>
>
> Ok, I agree here, that action plugins (and reporters as they are
> required by some analyzers??) may be enabled on demand without being
> listed in config file explicitly, so user doesn't even have to know that
> the "action" is done by some plugin. But I think it would be great to do
> some more surgery into abrt.conf e.g. move analyzer - reporter
> association from abrt.conf to per plugin conf.
>
>>
>> Actually, now that I looked at the code, I have a tangential question -
>> why we load *all* plugins, then *register* only some of them? This means
>> unused plugins still take up some memory, right? Why do we need two
>> different concepts of "loaded" and "registered"? One might be
enough...
>>
>
> 1. load all plugins to determine which plugins do we have (as we can't
> trust the config file :))
> 2. enable (run init() at least I hope it works that way) only those
> plugins we want (listed in conf file)
>
> So what is the proposal here? To load and enable all installed plugins?
Load and enable all plugins mentioned on 'EnabledPlugins = ...' line.
Then, if while executing any other directive we see a plugin
which is not loaded, load and enable it.
In C++ terms, "we see" means "GetAction(pluginName),
GetReporter(pluginName), etc are called"
--
vda
I was thinking about this and we still need to to have the option
Enabled in per plugin configuration, to be able to disable them - e.g.
disable the python plugin. We could leave it in the main abrt.conf, but
it's getting quite complex and I think *Enabled = yes|no* is easier to
parse/write then *EnabledPlugins = foo, bar, baz*
Jirka
10:28 a.m.
New subject: [Crash-catcher] auto-dlopening of plugins
On Fri, 2009-11-20 at 13:28 +0100, Jiri Moskovcak wrote:
>> 1. load all plugins to determine which plugins do we have
(as we can't
>> trust the config file :))
>> 2. enable (run init() at least I hope it works that way) only those
>> plugins we want (listed in conf file)
>>
>> So what is the proposal here? To load and enable all installed plugins?
>
> Load and enable all plugins mentioned on 'EnabledPlugins = ...' line.
> Then, if while executing any other directive we see a plugin
> which is not loaded, load and enable it.
>
> In C++ terms, "we see" means "GetAction(pluginName),
> GetReporter(pluginName), etc are called"
I was thinking about this and we still need to to have the option
Enabled in per plugin configuration, to be able to disable them - e.g.
disable the python plugin. We could leave it in the main abrt.conf, but
it's getting quite complex and I think *Enabled = yes|no* is easier to
parse/write then *EnabledPlugins = foo, bar, baz*
I think the location of "enabled" switch is not the topic of this
thread, we are discussing whether it makes sense to remove the
requirement that user must explicitly tweak "enable/disable" switch
when he already specified that plugin Foo should be run.
I agree that "Enabled = yes/no" should be moved to per-plugin
.conf file, I just did not get around to doing it yet.
--
vda
10:25 a.m.
New subject: [Crash-catcher] auto-dlopening of plugins
On Thu, 2009-11-19 at 15:44 +0100, Denys Vlasenko wrote:
> Ok, I agree here, that action plugins (and reporters as they are
> required by some analyzers??) may be enabled on demand without being
> listed in config file explicitly, so user doesn't even have to know that
> the "action" is done by some plugin. But I think it would be great to do
> some more surgery into abrt.conf e.g. move analyzer - reporter
> association from abrt.conf to per plugin conf.
>
> >
> > Actually, now that I looked at the code, I have a tangential question -
> > why we load *all* plugins, then *register* only some of them? This means
> > unused plugins still take up some memory, right? Why do we need two
> > different concepts of "loaded" and "registered"? One might
be enough...
> >
>
> 1. load all plugins to determine which plugins do we have (as we can't
> trust the config file :))
> 2. enable (run init() at least I hope it works that way) only those
> plugins we want (listed in conf file)
>
> So what is the proposal here? To load and enable all installed plugins?
Load and enable all plugins mentioned on 'EnabledPlugins = ...' line.
Then, if while executing any other directive we see a plugin
which is not loaded, load and enable it.
In C++ terms, "we see" means "GetAction(pluginName),
GetReporter(pluginName), etc are called"
Here is the patch which implements this.
With it, only EnabledPlugins = CCpp is needed.
Other plugins are loaded when they are used
for the first time. For example, KerneloopsScanner plugin
is loaded at the first Cron run.
RunApp plugin is loaded when a ccpp crash happens.
Bugzilla plugin is loaded when user decides to submit
the bug.
I run tested it: bot ccpp crashes and kernel oopses are detected.
--
vda
3:55 a.m.
New subject: [Crash-catcher] auto-dlopening of plugins
On 11/20/2009 05:25 PM, Denys Vlasenko wrote:
On Thu, 2009-11-19 at 15:44 +0100, Denys Vlasenko wrote:
>> Ok, I agree here, that action plugins (and reporters as they are
>> required by some analyzers??) may be enabled on demand without being
>> listed in config file explicitly, so user doesn't even have to know that
>> the "action" is done by some plugin. But I think it would be great to
do
>> some more surgery into abrt.conf e.g. move analyzer - reporter
>> association from abrt.conf to per plugin conf.
>>
>>>
>>> Actually, now that I looked at the code, I have a tangential question -
>>> why we load *all* plugins, then *register* only some of them? This means
>>> unused plugins still take up some memory, right? Why do we need two
>>> different concepts of "loaded" and "registered"? One
might be enough...
>>>
>>
>> 1. load all plugins to determine which plugins do we have (as we can't
>> trust the config file :))
>> 2. enable (run init() at least I hope it works that way) only those
>> plugins we want (listed in conf file)
>>
>> So what is the proposal here? To load and enable all installed plugins?
>
> Load and enable all plugins mentioned on 'EnabledPlugins = ...' line.
> Then, if while executing any other directive we see a plugin
> which is not loaded, load and enable it.
>
> In C++ terms, "we see" means "GetAction(pluginName),
> GetReporter(pluginName), etc are called"
Here is the patch which implements this.
With it, only EnabledPlugins = CCpp is needed.
Other plugins are loaded when they are used
for the first time. For example, KerneloopsScanner plugin
is loaded at the first Cron run.
RunApp plugin is loaded when a ccpp crash happens.
Bugzilla plugin is loaded when user decides to submit
the bug.
Hm, how does it work with gui, you can't change settings for disabled
plugin, so I guess it doesn't go well.
J.
I run tested it: bot ccpp crashes and kernel oopses are detected.
--
vda
6:44 a.m.
On Wed, 2009-11-18 at 16:03 +0100, Denys Vlasenko wrote:
Immediate planned work:
...
* Put text files _also_ in BZ comment field if they are small
(currently they are always attached).
Done in BZ plugin: any text attachment less than 1k in size
will be included in description too.
--
vda
9:48 a.m.
On Wed, 2009-11-18 at 16:03 +0100, Denys Vlasenko wrote:
* Design doc needs updating/consolidating:
doc/DESIGN and https://fedorahosted.org/abrt/wiki/AbrtArchitecture
Edited that web page. Please review.
--
vda
5290
days inactive
5297
days old
crash-catcher@lists.fedorahosted.org
13 comments
3 participants
participants (3)
-
Daniel Novotny -
Denys Vlasenko -
Jiri Moskovcak