Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Akonadi

  1. #1

    Default Akonadi

    I used locate to find some files and was surprised about some that it found. All for akonadi. So tried an fsck in my user space

    Code:
    john@dhcppc0:~> akonadictl fsck
    Akonadi Server is not running, check will not run
    The list of files locate produced is very long so this is a sample

    Code:
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_googlecalendar_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_googlecontacts_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_ical_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_icaldir_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_imap_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_invitations_agent.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_kalarm_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_knut_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_maildir_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_maildispatcher_agent.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_mailfilter_agent.mo

    As all are off / tried an fsck as root

    Code:
    hcppc0:/home/john # akonadictl fsck
    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/lib64/libexec/drkonqi from kdeinit
    sock_file=/kdeinit5__0
    Warning: connect() failed: : No such file or directory
    KCrash: Attempting to start /usr/lib64/libexec/drkonqi directly
    QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
    QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
    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
    
    [1]+  Stopped                 akonadictl fsck
    It looks like all of the files locate found by searching for akonadi do not relate to any software that I have installed so am tempted to empty the entire locale directory of folders that are just named with 2 letters. There are also a few odd one such as be@latin, ca@valencia, uk_UA. - sveral of the latter types with different _XX where the xx seems to indicate a country.

    I'm a bit mystified by where they come from especially as user data should b off ~~ now. Perhaps some on can explain. I don't have kmail or gmail installed and am a bit mystified by the presence that suggets facebook is involved.

    John
    -

  2. #2
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    25,240

    Default Re: Akonadi

    I am not sure I understand much about Akonadi, but as far as I know it is something that belogs to the KDE environment of each and every KDE user. Thus to me it looks very strange that you run akonadictrl as root, because
    • running it as another user then the user who has the problem will not help the user with the problem, at most the user without the probem;
    • root should not be a KDE user (never run any GUI as root), thus why using akonadictl on it's envoronment? It can only create a lot of rubbish in root's environment.

    But I may completely misunderstand Akonadi and KDE.
    Henk van Velden

  3. #3
    Join Date
    Jun 2008
    Location
    Groningen, Netherlands
    Posts
    19,972
    Blog Entries
    14

    Default Re: Akonadi

    Don't run akonadictl as root, it's supposed to run as your user, but needs akonadi to run.
    ° Appreciate my reply? Click the star and let me know why.

    ° Perfection is not gonna happen. No way.

    https://en.opensuse.org/openSUSE:Board#Members
    http://en.opensuse.org/User:Knurpht
    http://nl.opensuse.org/Gebruiker:Knurpht

  4. #4

    Default Re: Akonadi

    True but it's not running in my user space as the first code snippet shows.

    The other aspect is that I understand that full access to usr/share/locale needs root privileges and going on the 2nd code snippet it was running in root space but crashed while checking it's database. Not entirely sure but doesn't running at 1000 mean user and 0 would mean root or other way round. That's what seems to have caused it to crash.

    Something doesn't make much sense. Root ~ doesn't have any code at all installed in it according to a quick browse. Just 2 empty directories. It has had kde in it in the past.

    So why are there a lot of akonadi files in / usr/share/locale. I have a feeling that it may be garbage put in there by install.

    John
    -

  5. #5
    Join Date
    Jun 2008
    Location
    Groningen, Netherlands
    Posts
    19,972
    Blog Entries
    14

    Default Re: Akonadi

    Akonadi takes care of the database for kmail / Kontact.
    It should not run as root, since kmail/Kontact run as the user

    The garbage you're pointing at are translation files.
    ° Appreciate my reply? Click the star and let me know why.

    ° Perfection is not gonna happen. No way.

    https://en.opensuse.org/openSUSE:Board#Members
    http://en.opensuse.org/User:Knurpht
    http://nl.opensuse.org/Gebruiker:Knurpht

  6. #6
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    25,240

    Default Re: Akonadi

    Quote Originally Posted by John_82 View Post
    True but it's not running in my user space as the first code snippet shows.
    Whne you run everything, where (you think) that it gives you problems as normal user, as root, your system will be a major shipwreck in due course.

    Quote Originally Posted by John_82 View Post
    The other aspect is that I understand that full access to usr/share/locale needs root privileges
    When you mean with "full acess" read, write and execute, then that is true. Those are "system files" (in /usr) and maintained by root processes (mainly during installation) and are owned by root. And only root can change anything there (but everybody can read). As it should be, Normal users should not be able to change things there (and bork the system).

    Quote Originally Posted by John_82 View Post
    and going on the 2nd code snippet it was running in root space but crashed while checking it's database.
    Yes, as root (also a user) never uses KDE. it does not have all the KDE files that normal users may have (when they at least once used kde). Thus, to your luck, nothing, or almost nothing happened and it bailed out.

    Quote Originally Posted by John_82 View Post
    Not entirely sure but doesn't running at 1000 mean user and 0 would mean root or other way round. That's what seems to have caused it to crash.
    Those numbers (0 and 1000) are userids (UIDs) and they are what defines a user. UID 0 is better known by it's USERNAME root. And UID 1000 is better known by a name you have given to it. There are many others, but it is possible that you only know the USERNAME of UID 1000, because that is the USERNAME you normaly use to login and do your work. You may also have created more USERNAMEs for your wife, friend, son, daughter or any other identity (including yourself as e.g. charmain of a local club) you gave access to the system.

    Quote Originally Posted by John_82 View Post
    Something doesn't make much sense. Root ~ doesn't have any code at all installed in it according to a quick browse. Just 2 empty directories. It has had kde in it in the past.
    When you thouroughly understand all of the above, you will now understand that user root will (and should) NOT have any KDE related directories/files (not "code") in it's home directory. Simply because root has never loged in in the KDE GUI (or any other GUI).

    Quote Originally Posted by John_82 View Post
    So why are there a lot of akonadi files in / usr/share/locale. I have a feeling that it may be garbage put in there by install.
    There is no "garbage" there. Those are just the messages files used by applications (including Akonadi) when users specify that they prefer to see messages in a specific language. You will find there files for many applications. At installation each application may install message translation files there. And that includes Akonadi.
    As said above they are "system files", belong to system wide installed applications and as end-user, they are non of your bussiness.

    Please, as Linux user, try to understand the multi-user (and multi session) aspect of Unix/Linux to the full extend.
    And most important: do not run anything as root that is not needed to be run as root. And that includes of course stupid testing things that did not function as expected when run by a normal user.
    Henk van Velden

  7. #7
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    1,061

    Default Re: Akonadi

    Quote Originally Posted by John_82 View Post
    I used locate to find some files and was surprised about some that it found. All for akonadi. So tried an fsck in my user space

    Code:
    john@dhcppc0:~> akonadictl fsck
    Akonadi Server is not running, check will not run
    The list of files locate produced is very long so this is a sample

    Code:
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_googlecalendar_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_googlecontacts_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_ical_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_icaldir_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_imap_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_invitations_agent.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_kalarm_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_knut_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_maildir_resource.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_maildispatcher_agent.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_mailfilter_agent.mo

    As all are off / tried an fsck as root

    Code:
    hcppc0:/home/john # akonadictl fsck
    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/lib64/libexec/drkonqi from kdeinit
    sock_file=/kdeinit5__0
    Warning: connect() failed: : No such file or directory
    KCrash: Attempting to start /usr/lib64/libexec/drkonqi directly
    QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
    QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
    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
    
    [1]+  Stopped                 akonadictl fsck
    It looks like all of the files locate found by searching for akonadi do not relate to any software that I have installed so am tempted to empty the entire locale directory of folders that are just named with 2 letters. There are also a few odd one such as be@latin, ca@valencia, uk_UA. - sveral of the latter types with different _XX where the xx seems to indicate a country.

    I'm a bit mystified by where they come from especially as user data should b off ~~ now. Perhaps some on can explain. I don't have kmail or gmail installed and am a bit mystified by the presence that suggets facebook is involved.

    John
    -
    To identify the package owning a file run:

    Code:
    karl@erlangen:~/Downloads> rpm -qf /usr/share/locale/zh_CN/LC_MESSAGES/akonadi_mailfilter_agent.mo
    kmail-lang-19.04.3-1.1.noarch
    karl@erlangen:~/Downloads>
    Then you may remove the package owning the file:

    Code:
    erlangen:~ # zypper rm kmail-lang
    Loading repository data...
    Warning: No repositories defined. Operating only with the installed resolvables. Nothing can be installed.
    Reading installed packages...
    Resolving package dependencies...
    
    The following package is going to be REMOVED:
      kmail-lang
    
    1 package to remove.
    After the operation, 10.3 MiB will be freed.
    Continue? [y/n/v/...? shows all options] (y): n
    erlangen:~ #
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), openSUSE Tumbleweed, KDE Plasma 5

  8. #8

    Default Re: Akonadi

    Quote Originally Posted by hcvv View Post
    Please, as Linux user, try to understand the multi-user (and multi session) aspect of Unix/Linux to the full extend.
    And most important: do not run anything as root that is not needed to be run as root. And that includes of course stupid testing things that did not function as expected when run by a normal user.
    I do fully understand that and this is why I wonder why files are stored in root rather than user space off ~ or $HOME as KDE tends to call it. I am not running Akonadi as a user as no applications i have installed need it. The services are available so it would be loaded on log in if needed.

    Code:
    john@dhcppc0:~> akonadictl status
    Akonadi Control: stopped
    Akonadi Server: stopped
    Akonadi Server Search Support: available (Remote Search, Akonadi Search Plugin)
    Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_resource, akonadi_ews_resource, akonadi_ewsmta_resource, akonadi_facebook_resource, akonadi_followupreminder_agent, akonadi_googlecalendar_resource, akonadi_googlecontacts_resource, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonadi_indexing_agent, akonadi_invitations_agent, akonadi_kalarm_dir_resource, akonadi_kalarm_resource, akonadi_knut_resource, akonadi_kolab_resource, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_newmailnotifier_agent, akonadi_notes_agent, akonadi_notes_resource, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlater_agent, akonadi_tomboynotes_resource, akonadi_unifiedmailbox_agent, akonadi_vcard_resource, akonadi_vcarddir_resource
    Virtually all relate to the PIM one way or another including facilities that can be set on the digital clock. PIM content will vary according to the user so should be in a users own space and is there.

    I suppose the answer to my question is that the files in root space link in some way to Akonadi's services so are there even if a user doesn't want them. As they are kde specific not a problem - unlike applications where similar arrangements are used that effectively mean that all users finish up with the same applcations after an install - a disaster on 42.2 as it came especially if users wanted to run different desktops.

    John
    -

  9. #9
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    1,061

    Default Re: Akonadi

    Quote Originally Posted by John_82 View Post
    I do fully understand that and this is why I wonder why files are stored in root rather than user space off ~ or $HOME as KDE tends to call it. I am not running Akonadi as a user as no applications i have installed need it. The services are available so it would be loaded on log in if needed.

    Code:
    john@dhcppc0:~> akonadictl status
    Akonadi Control: stopped
    Akonadi Server: stopped
    Akonadi Server Search Support: available (Remote Search, Akonadi Search Plugin)
    Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_resource, akonadi_ews_resource, akonadi_ewsmta_resource, akonadi_facebook_resource, akonadi_followupreminder_agent, akonadi_googlecalendar_resource, akonadi_googlecontacts_resource, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonadi_indexing_agent, akonadi_invitations_agent, akonadi_kalarm_dir_resource, akonadi_kalarm_resource, akonadi_knut_resource, akonadi_kolab_resource, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_newmailnotifier_agent, akonadi_notes_agent, akonadi_notes_resource, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlater_agent, akonadi_tomboynotes_resource, akonadi_unifiedmailbox_agent, akonadi_vcard_resource, akonadi_vcarddir_resource
    Virtually all relate to the PIM one way or another including facilities that can be set on the digital clock. PIM content will vary according to the user so should be in a users own space and is there.

    I suppose the answer to my question is that the files in root space link in some way to Akonadi's services so are there even if a user doesn't want them. As they are kde specific not a problem - unlike applications where similar arrangements are used that effectively mean that all users finish up with the same applcations after an install - a disaster on 42.2 as it came especially if users wanted to run different desktops.

    John
    -
    Nope. See my previous post.
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), openSUSE Tumbleweed, KDE Plasma 5

  10. #10
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    25,240

    Default Re: Akonadi

    Quote Originally Posted by karlmistelberger View Post
    Nope. See my previous post.
    Isn't this thread running a bit out of control? In your previous post you even advised to de-install packages.

    What happens here is IMHO.

    The OP, as normal user, tried something to find on his system. He did not explain what he searched for, nor what tool he used, nor how he used that tool.

    He did not restrict his searching to his home directory and thus he found files which have the string akonadi somewhere in their name. Instead of simply conclude that those files most probably belong to all that is installed when you install KDE, he panicked and thought that there is something wrong with his personal Akonadi files/database/whatever. Which is of course not the case because those files are system files and not his personal Akonadi files.

    Having read somewwhere (on the infamous Internet?) that when having problems with Akonadi, you should run akonadictrl fsck, he did so without understanding what it will do.

    Then akonadi-fsck detected that akonadi is not running, so nothing to do. The OP, instead of concluding that he in fact has no problem at all (any Kmail problems, etc.?), switched to loging in as user root and did the same. Enough said about that panic action above.

    My conclusion.
    There is no system problem at all. The files found in /usr/share/locale are only some of the many more files there that are installed during installation of many applications.
    Don't touch them. Do not de-install anything. You will run into problems when you do.
    Last edited by hcvv; 26-Jul-2019 at 03:45.
    Henk van Velden

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •