Bug 559439 - /var/cache/abrt/ccpp* flowing over/abrts assigned to "root"
/var/cache/abrt/ccpp* flowing over/abrts assigned to "root"
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: abrt (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Moskovcak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-28 00:05 EST by Ralf Corsepius
Modified: 2015-02-01 17:50 EST (History)
9 users (show)

See Also:
Fixed In Version: abrt-1.0.7-1.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-23 00:39:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralf Corsepius 2010-01-28 00:05:56 EST
Description of problem:
Abrt only notifies users about segfaults this user is having.

Checking /var/cache/abrt, I just found ccpp*'s to pile up, which were caused programs running as "root" - No user ever was notified on them.

Version-Release number of selected component (if applicable):
abrt-1.0.4-1.fc12.x86_64

How reproducible:
Deterministic

Steps to Reproduce:
1. Install mock
2. Build packages in mock
3. Watch /var/cache/abrt
  
Actual results:
* /var/cache/abrt/ccpp*'s assigned to root piling up.
* No user being notified about the segfaults.

Expected results:
/var/cache/abrt/ not to gradually flow over.

On a wider scale, IMO, the abrt-devs will have to come up with a general concept of "user roles": Whom to notify, when, what to ignore, how to handle segfaults being owned by non-interactive users (setuid-progs, daemons, etc), garbage collection etc.

Additional info:
I only noticed this issue, when abrt once complained about "exceeding quota" on a segfault of a user-owned program. As I don't have quota's enabled and have plenty of disk-space (>2TB), I found /var/cache/abrt to be gradually filling up.
Comment 1 Ralf Corsepius 2010-01-28 01:34:16 EST
c.f. https://bugzilla.redhat.com/show_bug.cgi?id=559451
Comment 2 Jiri Moskovcak 2010-02-08 18:30:28 EST
(In reply to comment #0)
> Description of problem:
> Abrt only notifies users about segfaults this user is having.

Yes, this is the default setting for abrt. It can be changed by adding line: InformAllUsers = yes to the respective analyzer plugin's config file.

> Checking /var/cache/abrt, I just found ccpp*'s to pile up, which were caused
> programs running as "root" - No user ever was notified on them.
> 

you'd see them in gui if you run it as root.

> 
> Actual results:
> * /var/cache/abrt/ccpp*'s assigned to root piling up.
> * No user being notified about the segfaults.
> 

As I said, this is by design and no, it's not a mistake. We don't want to expose
crashes in daemons to non-root users, but if admin want's it he can enable it.

> Expected results:
> /var/cache/abrt/ not to gradually flow over.
> 

It doesn't flow over the quota specified in /etc/abrt.conf:
MaxCrashReportsSize = 1000

> Additional info:
> I only noticed this issue, when abrt once complained about "exceeding quota" on
> a segfault of a user-owned program. As I don't have quota's enabled and have
> plenty of disk-space (>2TB), I found /var/cache/abrt to be gradually filling
> up.    

You're wrong, abrt don't exceed it's quota and the pop-up proves, that the qouta actually works.
Comment 3 Ralf Corsepius 2010-02-08 20:37:31 EST
(In reply to comment #2)

> > Checking /var/cache/abrt, I just found ccpp*'s to pile up, which were caused
> > programs running as "root" - No user ever was notified on them.
> > 
> 
> you'd see them in gui if you run it as root.
Run a gui as root? 

With all due respect, do YOU really know what you are saying?
IMSHO, you have DISQUALIFIED yourselves from any further discussion.

> > Additional info:
> > I only noticed this issue, when abrt once complained about "exceeding quota" on
> > a segfault of a user-owned program. As I don't have quota's enabled and have
> > plenty of disk-space (>2TB), I found /var/cache/abrt to be gradually filling
> > up.    
> 
> You're wrong, abrt don't exceed it's quota and the pop-up proves, that the
> qouta actually works.    

Well, "quota exceeded" is the wording the pop-up uses.

And it what actually happened: The a pile of ccpp's in /var/cache/abrt owned by "root" had filled up to the limit, preventing further ones to be added.
Comment 4 Denys Vlasenko 2010-02-08 22:35:14 EST
We recently found and fixed a bug where repeated duplicate crash dumps were not deleted. As it is fixed, I am setting this bug to MODIFIED.

If you want to see all crashes with all UIDs, even if you are logged in as non-root, set InformAllUsers = yes
in /etc/abrt/plugins/CCpp.conf

I am happy to know that abrtd's overflow-protection works... your disk wasn't filled up, /var/cache/abrt stopped at 1 Gb (right?) (abrt.conf: MaxCrashReportsSize = 1000)
Comment 5 Jiri Moskovcak 2010-02-09 03:52:56 EST
(In reply to comment #3)
> (In reply to comment #2)
> 
> > > Checking /var/cache/abrt, I just found ccpp*'s to pile up, which were caused
> > > programs running as "root" - No user ever was notified on them.
> > > 
> > 
> > you'd see them in gui if you run it as root.
> Run a gui as root? 
> 
> With all due respect, do YOU really know what you are saying?
> IMSHO, you have DISQUALIFIED yourselves from any further discussion.
> 

So there is no other gui that needs to be run with root privs? what about s-c-network and other tools using console-helper?  If you don't like GUI with root privs, then you can use abrt-cli, if it's X-less box.

> > > Additional info:
> > > I only noticed this issue, when abrt once complained about "exceeding quota" on
> > > a segfault of a user-owned program. As I don't have quota's enabled and have
> > > plenty of disk-space (>2TB), I found /var/cache/abrt to be gradually filling
> > > up.    
> > 
> > You're wrong, abrt don't exceed it's quota and the pop-up proves, that the
> > qouta actually works.    
> 
> Well, "quota exceeded" is the wording the pop-up uses.
> 
> And it what actually happened: The a pile of ccpp's in /var/cache/abrt owned by
> "root" had filled up to the limit, preventing further ones to be added.

We don't understand each other here. The "quota exceeded" is the right wording here, it means abrt's quota set in abrt.conf and has nothing to do with system quotas. It was a RFE to make abrt not fill-up the whole disk and stop on some limit and this is what happened, so I don't understand what is wrong with that.

Have a nice day,
Jirka
Comment 6 Fedora Update System 2010-02-15 09:07:48 EST
abrt-1.0.7-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/abrt-1.0.7-1.fc12
Comment 7 Fedora Update System 2010-02-18 17:31:37 EST
abrt-1.0.7-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update abrt'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1598
Comment 8 Fedora Update System 2010-02-23 00:37:38 EST
abrt-1.0.7-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.