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...)
--
vda