General support questions
- Posts: 71
- Joined: 2019/09/23 15:26:45
The last few days I've had an annoying 'abrt-cli status' timed out
every time I start a terminal window. Running abrt-cli status -v
manually gave me:
Code: Select all
Private Reports is enabled, use 'abrt-cli -a COMMAND' to get the detected problems.
Can't get problem list from abrt-dbus: Timeout was reached
Apparently abrt-dbus is not running as a daemon, at least there is no such service. Searched the internet and some years back there was a bug report on Red Hat with the same timeout problem. There the solution was to install abrt-dbus as it apparently not was a dependency at that time but was to be as a bug fix. Since things used to work without it I tried killing the process and the abrt-cli timeout problem disappeared. Perhaps I can live without abrt-dbus but I would prefer to get the problem fixed. abrt-dbus was started with the argument -t133 i.e. it shuts itself off after 133s of inactivity. It is started by the dbus daemon. I checked the status of dbus and it was ok and didn't show any complains since I killed abrt-dbus. But abrt-cli didn't wait that long but it did wait some time for abrt-dbus but apparenlty seeing that it was not running ignored it. The thing to try was of course to restart abrt-dbus but I took a more drastic approach and restarted the entire dbus. Don't do that!
Well, it worked but I had to log in again etc. Now abrt-dbus is running and abrt-cli doesn't time out so apparently abrt-cli gets an answer from abrt-dbus in a timely manner. But I am a bit puzzled. I tried rebooting the machine before foolishly restarting dbus and that did not remedy the abrt-cli timeout problem. Why not, I wonder, as it also restarted the dbus. Were there left-overs from abrt-dbus that didn't go away during reboot but did so when I restarted dbus? Anyway, next time the problem shows up I'll go for restarting abrt-dbus only.
Desktop Dell T5810 Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz, 72 GB RAM, Radeon Pro WX 7100