On 07/14/2014 12:27 PM, Robert P. J. Day wrote:
On Mon, 14 Jul 2014, Adam Williamson wrote:
On Mon, 2014-07-14 at 13:27 -0400, Robert P. J. Day wrote:
When one of these journalctl processes is running, 'systemctl status
(pid of that process)' may tell you what service is spawning it. --
i'll set aside some time this evening to look at this, but i just
want to confirm that i'm not the only person seeing this -- that is,
i have a quad core i7 with hyperthreading so i have 8 possible CPUs
and, without messing with any kind of related configuration, i've seen
this system with 7 journalctl processes running, each one pegged at
98-99% CPU. and that's more than enough to have the fans on this thing
running full blast to keep it from melting down. :-(
and doing a "systemctl restart abrtd" didn't appear to solve the
problem. more this evening after some testing ...
I asked at the meeting this morning, and nirik said he'd seen it but
only once, could not reproduce it any more. The rest of us aren't seeing
it (or at least haven't *noticed* it).
ok, i just rebooted and, within a minute, a journalctl was invoked
that almost immediately sucked up 99% CPU. so i checked its status via
PID and got:
$ systemctl status 4230
● abrtd.service - ABRT Automated Bug Reporting Tool
Loaded: loaded (/usr/lib/systemd/system/abrtd.service; enabled)
Active: active (running) since Mon 2014-07-14 15:14:51 EDT; 8min ago
Main PID: 801 (abrtd)
CGroup: /system.slice/abrtd.service
├─ 801 /usr/sbin/abrtd -d -s
├─4016 abrt-server -s
├─4017 /usr/libexec/abrt-handle-event -i -e post-create -- /var/tmp/abrt/ccpp-2014-07-14-15:20:51-2330
├─4070 abrt-server -s
├─4071 /usr/libexec/abrt-handle-event -i -e post-create -- /var/tmp/abrt/ccpp-2014-07-14-15:21:23-4057
├─4197 /bin/sh -c if grep '^TracerPid:[[:space:]]*[123456789]' proc_pid_status >/dev/null 2>&1; then # We see 'TracerPid: <nonzero...
├─4205 abrt-server -s
├─4206 /usr/libexec/abrt-handle-event -i -e post-create -- /var/tmp/abrt/ccpp-2014-07-14-15:22:32-4202
├─4219 /bin/sh -c if grep '^TracerPid:[[:space:]]*[123456789]' proc_pid_status >/dev/null 2>&1; then # We see 'TracerPid: <nonzero...
├─4229 /bin/sh -c if grep '^TracerPid:[[:space:]]*[123456789]' proc_pid_status >/dev/null 2>&1; then # We see 'TracerPid: <nonzero...
├─4230 journalctl _UID=0 -b
├─4231 grep -F -e packagekitd
└─4232 tail -99
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: Unlocked '/var/tmp/abrt/ccpp-2014-05-12-10:31:33-2547/.lock' (no or corrupted 'time' file)
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: Missing file: time
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: Unlocked '/var/tmp/abrt/oops-2014-04-06-05:46:42-25982-1/.lock' (no or corrupted 'time' file)
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: Missing file: time
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: Unlocked '/var/tmp/abrt/ccpp-2014-05-12-10:31:33-2547/.lock' (no or corrupted 'time' file)
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: '/var/tmp/abrt/ccpp-2014-05-12-10:31:33-2547' is not a problem directory
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: Missing file: time
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: Unlocked '/var/tmp/abrt/oops-2014-06-19-05:49:38-1919-0/.lock' (no or corrupted 'time' file)
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: Missing file: time
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: Unlocked '/var/tmp/abrt/oops-2014-04-06-05:46:42-25982-1/.lock' (no or corrupted 'time' file)
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: Missing file: time
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: Unlocked '/var/tmp/abrt/oops-2014-06-19-05:49:38-1919-0/.lock' (no or corrupted 'time' file)
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: Missing file: time
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: Unlocked '/var/tmp/abrt/oops-2014-04-06-05:46:42-25982-1/.lock' (no or corrupted 'time' file)
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: Missing file: time
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: Unlocked '/var/tmp/abrt/oops-2014-06-19-05:49:38-1919-0/.lock' (no or corrupted 'time' file)
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: Missing file: time
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: Unlocked '/var/tmp/abrt/oops-2014-04-06-05:46:42-25982-1/.lock' (no or corrupted 'time' file)
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: '/var/tmp/abrt/oops-2014-04-06-05:46:42-25982-1' is not a problem directory
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: Missing file: time
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: Unlocked '/var/tmp/abrt/oops-2014-06-20-06:21:16-848-0/.lock' (no or corrupted 'time' file)
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: Missing file: time
Jul 14 15:23:14 localhost.localdomain abrt-server[4205]: Unlocked '/var/tmp/abrt/oops-2014-06-19-05:49:38-1919-0/.lock' (no or corrupted 'time' file)
Jul 14 15:23:14 localhost.localdomain abrt-server[4070]: Missing file: time
... etc etc ...
thoughts?
rday
Looks like https://bugzilla.redhat.com/show_bug.cgi?id=1048279
From Comment#2:
The problem here is that some tmp-files-cleaner has cleared contents of your dump directories and
left the empty directories in the dump location. Removing of the empty directories from
'/var/tmp/abrt' should help in this case.
.. more details in the bug report. Still flagged as open.
-Bob Arendt
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
