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@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
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
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
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
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
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
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...
- 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
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...
- 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
On Fri, 2009-11-20 at 13:28 +0100, Jiri Moskovcak wrote:
- 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
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...
- 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
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...
- 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
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
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
crash-catcher@lists.fedorahosted.org
-
Daniel Novotny -
Denys Vlasenko -
Jiri Moskovcak