On Wed, 2011-01-26 at 21:15 +0100, Jiri Moskovcak wrote:
On 01/26/2011 08:24 PM, Denys Vlasenko wrote:
Hi,
After a quick look at abrt-cli source, I think this can be approached like this:
We add -D DIR option which specifies which directory to list. It can be used more than once. If it is not specified, abrt-cli defaults to -D /var/spool/abrt -D $HOME/abrt/spool.
With "abrt-cli --list", dumps from all these directories are shown.
- what are you going to show here?
The same thing we already show:
# abrt-cli --list --full Getting crash infos... 0. Crash dump : /var/spool/abrt/ccpp-1294848465-26639 UID : 0 Package : coreutils-8.4-10.fc13 Executable : /bin/sleep Crash Time : Wed 12 Jan 2011 05:07:45 PM CET Crash Count: 4 Hostname : dhcp-25-227.brq.redhat.com 1. Crash dump : /var/spool/abrt/ccpp-1294848466-26657 UID : 0 Package : hdparm-9.27-1.fc13 Executable : /sbin/hdparm Crash Time : Wed 12 Jan 2011 05:07:46 PM CET Crash Count: 1 Hostname : dhcp-25-227.brq.redhat.com
if the second then you'll hit the locking problem again.. unless you ask the daemon to give you the data...
What problem? The dump which can't be locked for writing may be still possible to read. If it can't be read too, then we don't show it.
When "abrt-cli --report DUMP_DIR" is run and abrt-cli detects that it can't lock DUMP_DIR for writing, it informs the user:
DUMP_DIR is not writable. Do you want to copy it to $HOME/abrt/spool? (y/n)
(The directory to copy to can be specified by another option, -W DIR; or we can have a convention that the DIR from the first -D DIR option is used)
- this sounds ok
When "abrt-cli --delete DUMP_DIR" is run and abrt-cli detects that it can't lock DUMP_DIR for writing, it tries to delete the directory through dbus call to abrtd.
- I'm ok with this, but at one point we will have to make the surgery
and cut the dbus from daemon (or we can leave it if we can live with the dbus dependency...)