Bug 384557 - "akonadictl status" crashes
Summary: "akonadictl status" crashes
Status: RESOLVED NOT A BUG
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: akonadiconsole (show other bugs)
Version: 5.4.3
Platform: Mageia RPMs Linux
: NOR crash
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-10 11:44 UTC by Olivier Delaune
Modified: 2017-09-10 18:16 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Delaune 2017-09-10 11:44:44 UTC
If I type "akonadi status" in a terminal, I get

QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
D-Bus session bus is not available!
KCrash: Application 'akonadictl' crashing...
KCrash: Attempting to start /usr/libexec/drkonqi from kdeinit
sock_file=/kdeinit5__0
Warning: connect() failed: : Connexion refusée
KCrash: Attempting to start /usr/libexec/drkonqi directly
found lsb_release
Using /proc to determine executable path
Executable is: "/usr/bin/akonadictl"
Executable exists: true
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
Enabling drkonqi crash catching
kf5.kwidgetsaddons: Invalid pixmap specified.
Sending SIGSTOP to process

The backtrace I get is:

Application: akonadictl (akonadictl), signal: Aborted
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f9ce5518800 (LWP 14969))]

Thread 2 (Thread 0x7f9cda3b4700 (LWP 14970)):
#0  0x00007f9ce491c48a in QMutex::lock() () at /lib64/libQt5Core.so.5
#1  0x00007f9ce4b394bb in postEventSourcePrepare(_GSource*, int*) () at /lib64/libQt5Core.so.5
#2  0x00007f9ce195e22d in g_main_context_prepare () at /lib64/libglib-2.0.so.0
#3  0x00007f9ce195ebc3 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#4  0x00007f9ce195ed9c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#5  0x00007f9ce4b39e2b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#6  0x00007f9ce4ae549a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#7  0x00007f9ce491f3bc in QThread::exec() () at /lib64/libQt5Core.so.5
#8  0x00007f9ce55cd635 in QDBusConnectionManager::run() () at /lib64/libQt5DBus.so.5
#9  0x00007f9ce4923ff9 in QThreadPrivate::start(void*) () at /lib64/libQt5Core.so.5
#10 0x00007f9ce3d1a66d in start_thread () at /lib64/libpthread.so.0
#11 0x00007f9ce4025e4d in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x7f9ce5518800 (LWP 14969)):
[KCrash Handler]
#4  0x00007f9ce3f63818 in raise () at /lib64/libc.so.6
#5  0x00007f9ce3f64f2a in abort () at /lib64/libc.so.6
#6  0x000000000040ab83 in akMessageHandler(QtMsgType, QMessageLogContext const&, QString const&) (type=<optimized out>, context=..., msg=...) at /usr/src/debug/akonadi-16.12.3/src/shared/akdebug.cpp:169
#7  0x00007f9ce490a6c8 in qt_message(QtMsgType, QMessageLogContext const&, char const*, __va_list_tag*) () at /lib64/libQt5Core.so.5
#8  0x00007f9ce490bf56 in QMessageLogger::fatal(char const*, ...) const () at /lib64/libQt5Core.so.5
#9  0x0000000000409df3 in AkApplicationBase::init() (this=this@entry=0x7ffff9ae57b0) at /usr/src/debug/akonadi-16.12.3/src/shared/akapplication.cpp:65
#10 0x0000000000405a6f in AkApplicationImpl<QCoreApplication>::AkApplicationImpl(int&, char**, QLoggingCategory const&) (loggingCategory=..., argv=0x7ffff9ae5958, argc=@0x7ffff9ae556c: 2, this=0x7ffff9ae57b0) at /usr/src/debug/akonadi-16.12.3/src/shared/akapplication.h:83
#11 0x0000000000405a6f in main(int, char**) (argc=2, argv=0x7ffff9ae5958) at /usr/src/debug/akonadi-16.12.3/src/akonadictl/main.cpp:182

Note that it does not happen just after I reboot but after a while (few hours?), akonadi stps working and when I wanted to see what happens, I get this crash. I am not able to restart akonadi without reboot my computer.
Comment 1 Christophe Marin 2017-09-10 18:16:03 UTC
> QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0

Looks like something is modifying permissions. When this happens, check whether your user can read / write /run/user/1000.

This has nothing to do with Akonadi however.