Akonadi

English Applications
1

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


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


/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


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

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.

3

Don’t run akonadictl as root, it’s supposed to run as your user, but needs akonadi to run.

4

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

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.

6

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.

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).

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.

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.

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).

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.

7

To identify the package owning a file run:

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:

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:~ #
8

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.


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

Nope. See my previous post.

10

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.

11

The Op said:

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.
From this I concluded that he does not need kmail-lang either and can be be safely deleted.

12

I see, but let us wait what the OP says and if he realy is trying to eliminate every file he thinks he does not need.

13

There is a caveat:

https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/static/images/icon-warning.png**Warning: Do Not Remove Mandatory System Packages**

 Do not remove mandatory system packages like     glibc     ,     zypper     ,     kernel     . If they are removed, the system can become unstable or stop working     altogether.

https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.sw_cl.html