..if you use postgresql as database backend. With mySQL the database is shut down properly
Can't reproduce here. I didn't see this issue since ages.
docb@T520:~> ps ax | grep postgre 10238 ? S 0:00 /usr/lib/postgresql96/bin/postgres -D /home/docb/.local/share/akonadi/db_data -k/tmp/akonadi-docb.N9ni6K -h 10239 ? Ss 0:00 postgres: logger process 10241 ? Ss 0:00 postgres: checkpointer process 10242 ? Ss 0:00 postgres: writer process 10243 ? Ss 0:00 postgres: wal writer process 10244 ? Ss 0:00 postgres: autovacuum launcher process 10245 ? Ss 0:00 postgres: stats collector process 10249 ? Ss 0:00 postgres: docb akonadi [local] idle 10256 ? Ss 0:00 postgres: docb akonadi [local] idle 10257 ? Ss 0:00 postgres: docb akonadi [local] idle 10278 ? Ss 0:00 postgres: docb akonadi [local] idle 10286 ? Ss 0:00 postgres: docb akonadi [local] idle 10292 ? Ss 0:00 postgres: docb akonadi [local] idle 10295 ? Ss 0:00 postgres: docb akonadi [local] idle 10296 ? Ss 0:00 postgres: docb akonadi [local] idle 10298 ? Ss 0:00 postgres: docb akonadi [local] idle 10301 ? Ss 0:00 postgres: docb akonadi [local] idle 10302 ? Ss 0:00 postgres: docb akonadi [local] idle 10303 ? Ss 0:00 postgres: docb akonadi [local] idle 10325 ? Ss 0:00 postgres: docb akonadi [local] idle 10327 ? Ss 0:00 postgres: docb akonadi [local] idle 10333 ? Ss 0:00 postgres: docb akonadi [local] idle 10344 ? Ss 0:00 postgres: docb akonadi [local] idle 10348 ? Ss 0:00 postgres: docb akonadi [local] idle 10352 ? Ss 0:00 postgres: docb akonadi [local] idle 10354 ? Ss 0:00 postgres: docb akonadi [local] idle 10359 ? Ss 0:00 postgres: docb akonadi [local] idle 10365 ? Ss 0:00 postgres: docb akonadi [local] idle 10371 ? Ss 0:00 postgres: docb akonadi [local] idle 10375 ? Ss 0:00 postgres: docb akonadi [local] idle 10376 ? Ss 0:00 postgres: docb akonadi [local] idle 10377 ? Ss 0:00 postgres: docb akonadi [local] idle 10379 ? Ss 0:00 postgres: docb akonadi [local] idle 10382 ? Ss 0:00 postgres: docb akonadi [local] idle 10385 ? Ss 0:00 postgres: docb akonadi [local] idle 10389 ? Ss 0:00 postgres: docb akonadi [local] idle 10398 ? Ss 0:00 postgres: docb akonadi [local] idle 10401 ? Ss 0:00 postgres: docb akonadi [local] idle 10488 pts/1 R+ 0:00 grep --color=auto postgre docb@T520:~> akonadictl stop --verbose docb@T520:~> org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_sendlater_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_mailfilter_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_imap_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_imap_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_imap_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_newmailnotifier_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_followupreminder_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_googlecontacts_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_imap_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_maildir_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_maildispatcher_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_notes_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_indexing_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_imap_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_contacts_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_imap_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_archivemail_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_migration_agent' exited normally... chainup() org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally... docb@T520:~> ps ax | grep postgre 10238 ? S 0:00 /usr/lib/postgresql96/bin/postgres -D /home/docb/.local/share/akonadi/db_data -k/tmp/akonadi-docb.N9ni6K -h 10239 ? Ss 0:00 postgres: logger process 10241 ? Ss 0:00 postgres: checkpointer process 10242 ? Ss 0:00 postgres: writer process 10243 ? Ss 0:00 postgres: wal writer process 10244 ? Ss 0:00 postgres: autovacuum launcher process 10245 ? Ss 0:00 postgres: stats collector process 10511 pts/1 S+ 0:00 grep --color=auto postgre docb@T520:~>
I can confirm this (on a ThinkPad T520 as well:): Akonadi 5.9.3 (from Akonadi/KDEPIM 18.08), no selectable in bugtracker. SUMMARY 'akonadictl stop' does not quit PostgreSQL server. STEPS TO REPRODUCE 1. 'akonadictl stop' while Akonadi and PostgreSQL are running OBSERVED RESULT % akonadictl start Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) % Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) % akonadictl stop % QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open Error writing to file... [… don't know what this is about …] QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_birthdays_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_indexing_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_contacts_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_notes_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_newmailnotifier_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_mbox_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_followupreminder_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_akonotes_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_migration_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_sendlater_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_akonotes_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_mailfilter_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_maildir_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_pop3_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_maildispatcher_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_archivemail_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_icaldir_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_pop3_resource' exited normally... org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally... Time after quitting Akonadi: % date Sa 27. Apr 10:51:51 CEST 2019 More than 5 minutes later: % date Sa 27. Apr 10:57:18 CEST 2019 % ps aux | grep "[p]ostgres" martin 15222 0.0 0.1 212476 26288 ? S 10:50 0:00 /usr/lib/postgresql/11/bin/postgres -D /home/martin/.local/share/akonadi/db_data -k/tmp/akonadi-martin.wTqoXj -h martin 15224 0.0 0.1 212632 25388 ? Ss 10:50 0:00 postgres: checkpointer martin 15225 0.0 0.0 212476 5740 ? Ss 10:50 0:00 postgres: background writer martin 15226 0.0 0.0 212476 9476 ? Ss 10:50 0:00 postgres: walwriter martin 15227 0.0 0.0 212884 6412 ? Ss 10:50 0:00 postgres: autovacuum launcher martin 15228 0.0 0.0 67528 4924 ? Ss 10:50 0:00 postgres: stats collector martin 15229 0.0 0.0 212876 6484 ? Ss 10:50 0:00 postgres: logical replication launcher PostgreSQL however exits gracefully if asked to % kill 15222 % ps aux | grep "[p]ostgres" % EXPECTED RESULT PostgreSQL is properly terminated every time. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.9.3 (Akonadi/KDEPIM 18.08) (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.54 Qt Version: 5.11.3 ADDITIONAL INFORMATION PostgreSQL 11.2-2 as packaged in Debian Sid. Probably related, but as far as I can see 'akonadictl stop' returns 0 as exit code here and Akonadi does not seem to crash on exit. Bug 361675 - Akonadictl stop return exit 255 (postgresql)
These versions are obsolete, retry with a recent one.
18.08 unmaintained already? Well, FWIW Dan asked me whether Akonadi crashes which may prevent a proper database shutdown¹. Now I did and even used an existing bug report and you just closed it. That basically means that as long as I choose to use the Debian Sid aka Unstable release (not even the one in current Debian Stretch aka Stable) and report any bugs about it, my bugs would be outdated to begin with. My short comment on this: I disagree. [1] https://mail.kde.org/pipermail/kdepim-users/2019-April/001827.html
Thing is: yes, I understand that it would be tedious to receive bug reports of long fixed bugs with versions that are 2 or more years old. But 18.08 is not even a year. If you are implying that you are not interested in bug reports regarding versions that are not even a year old, you are basically telling Linux distro users to get lost.
I'm running latest KDE on openSUSE Tumbleweed: Plasma 5.15.4 Framework 5.57.0 QT: 5.12.2 and can confirm that the issue persists: docb@T520:~> 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 docb@T520:~> ps ax | grep postgres 2893 ? S 0:00 /usr/lib/postgresql96/bin/postgres -D /home/docb/.local/share/akonadi/db_data -k/tmp/akonadi-docb.N9ni6K -h 2896 ? Ss 0:00 postgres: logger process 2900 ? Ss 0:06 postgres: checkpointer process 2901 ? Ss 0:01 postgres: writer process 2902 ? Ss 0:01 postgres: wal writer process 2903 ? Ss 0:00 postgres: autovacuum launcher process 2904 ? Ss 0:04 postgres: stats collector process 14412 pts/1 S+ 0:00 grep --color=auto postgres
Thank you Axel for confirming on recent version.
(In reply to Martin Steigerwald from comment #8) > Thank you Axel for confirming on recent version. I forgot: ocb@T520:~> rpm -qa | grep akonadi akonadi-calendar-lang-18.12.3-1.2.noarch akonadi-server-18.12.3-2.1.x86_64 akonadi-plugin-mime-18.12.3-1.2.x86_64 akonadi-calendar-tools-lang-18.12.3-1.2.noarch akonadi-plugin-kalarmcal-18.12.3-1.2.x86_64 akonadi-import-wizard-lang-18.12.3-1.2.noarch akonadi-search-18.12.3-1.2.x86_64 akonadi-notes-lang-18.12.3-1.2.noarch akonadi-mime-18.12.3-1.2.x86_64 akonadi-server-lang-18.12.3-2.1.noarch akonadi-calendar-tools-18.12.3-1.2.x86_64 akonadiconsole-18.12.3-1.2.x86_64 akonadi-contact-18.12.3-1.2.x86_64 akonadi-plugin-contacts-18.12.3-1.2.x86_64 akonadi-plugin-calendar-18.12.3-1.2.x86_64 akonadi-import-wizard-18.12.3-1.2.x86_64 akonadi-contact-lang-18.12.3-1.2.noarch akonadi-search-lang-18.12.3-1.2.noarch akonadi-mime-lang-18.12.3-1.2.noarch
I've experienced the bug, but with mysql not postgres, on an almost daily basis with all 18.12.* release aka 5.10.* . (I use KDE Neon User) With 18.12.* I've seen again after a long time the multiple merge candidate bugs and suddenly had duzends of items with "no RID". (5.10 almost drive me crazy.) I always assumed that those problems trigger the "mysql server not stopped by 'akonadictl stop'". So I'm not astonished that the bug is to reproducable for everyone. IMHO you should bump the "version" of this bug from 5.6.1 to 5.10.3. Achim
Achim, thanks. Updated version number. So you see mysqld process around even five minutes after "akonadictl stop"? Please report your findings regarding "items without RID" on: Bug 406856 Found 3734 items without RID.; Item "30024" has RID and is dirty. (Please always put new information on the relevant bug report, to help to keep each bug report concise and to one topic.) I update version number there as well then.
Application 19.04 does not stop DB either
Can you get full debug logs of the Akonadi Server, please? You can do so by starting Akonadi manually from the commandline: akonadictl --verbose start ... (wait for a bit) akonadictl stop You can retrieve the full logfile from ~/.local/share/akonadi/akonadiserver.error
Created attachment 120920 [details] error log After the akonadiserver claimed 'Database is no longer running': docb@T520:~> ps ax | grep postgres 7817 ? S 0:00 /usr/lib/postgresql11/bin/postgres -D /home/docb/.local/share/akonadi/db_data -k/tmp/akonadi-docb.N9ni6K -h 7819 ? Ss 0:00 postgres: logger 7821 ? Ss 0:00 postgres: checkpointer 7822 ? Ss 0:00 postgres: background writer 7823 ? Ss 0:00 postgres: walwriter 7824 ? Ss 0:00 postgres: autovacuum launcher 7825 ? Ss 0:00 postgres: stats collector 7826 ? Ss 0:00 postgres: logical replication launcher
Created attachment 120923 [details] akonadiserver.error log with akonadictl --verbose start With KDEPIM/Akonadi 18.08 (I know, still outdated, Debian in deep freeze till likely beginning of July) I can confirm Axel's results. Logfile attached. Some database processes are still running. % ps aux | grep postgres martin 25164 0.0 0.1 214568 26444 ? S 19:59 0:00 /usr/lib/postgresql/11/bin/postgres -D /home/martin/.local/share/akonadi/db_data -k/tmp/akonadi-martin.wTqoXj -h martin 25166 0.0 0.0 214568 3928 ? Ss 19:59 0:00 postgres: checkpointer martin 25167 0.0 0.0 214568 5600 ? Ss 19:59 0:00 postgres: background writer martin 25168 0.0 0.0 214568 9496 ? Ss 19:59 0:00 postgres: walwriter martin 25169 0.0 0.0 214976 6508 ? Ss 19:59 0:00 postgres: autovacuum launcher martin 25170 0.0 0.0 69616 5108 ? Ss 19:59 0:00 postgres: stats collector martin 25171 0.0 0.0 214968 6484 ? Ss 19:59 0:00 postgres: logical replication launcher martin 25400 0.0 0.0 8236 928 pts/3 S+ 20:01 0:00 grep postgres However if I do not stop the database processes manually it reuses the existing PostgreSQL processes as I show in my next attachment.
Created attachment 120924 [details] akonadiserver.error log with akonadictl --verbose start on second start reusing existing PostgreSQL processes On second start with some of the PostgreSQL processes still running, this happens: Found pg_ctl: "/usr/lib/postgresql/11/bin/pg_ctl" Found initdb: "/usr/lib/postgresql/11/bin/pg_ctl" Found a postmaster.pid pidfile, checking whether the server is still running... PostgreSQL for Akonadi is already running, trying to connect to it. Database "akonadi" opened using driver "QPSQL" DbInitializer::run() checking table "SchemaVersionTable" checking table "ResourceTable" It reuses the PostgreSQL processes that were left over from the last akonadictl stop: % ps aux | grep postgres martin 25164 0.0 0.1 214568 26444 ? S 19:59 0:00 /usr/lib/postgresql/11/bin/postgres -D /home/martin/.local/share/akonadi/db_data -k/tmp/akonadi-martin.wTqoXj -h martin 25166 0.0 0.1 214696 19412 ? Ss 19:59 0:00 postgres: checkpointer martin 25167 0.0 0.0 214700 9152 ? Ss 19:59 0:00 postgres: background writer martin 25168 0.0 0.0 214568 9496 ? Ss 19:59 0:00 postgres: walwriter martin 25169 0.0 0.0 214976 6508 ? Ss 19:59 0:00 postgres: autovacuum launcher martin 25170 0.0 0.0 69616 5108 ? Ss 19:59 0:00 postgres: stats collector martin 25171 0.0 0.0 214968 6484 ? Ss 19:59 0:00 postgres: logical replication launcher martin 25507 1.4 0.9 229764 160720 ? Ss 20:04 0:02 postgres: martin akonadi [local] idle martin 25516 0.0 0.0 218628 14992 ? Ss 20:04 0:00 postgres: martin akonadi [local] idle martin 25517 0.0 0.0 218628 15052 ? Ss 20:04 0:00 postgres: martin akonadi [local] idle martin 25567 0.0 0.0 218492 12980 ? Ss 20:04 0:00 postgres: martin akonadi [local] idle [… about 20-30 more of these …] if you compare this with my last comment, you see that the PIDs are exactly the same. However there are some additional processes running now. When I stop Akonadi again the following processes remain: % ps aux | grep postgres martin 25164 0.0 0.1 214568 26444 ? S 19:59 0:00 /usr/lib/postgresql/11/bin/postgres -D /home/martin/.local/share/akonadi/db_data -k/tmp/akonadi-martin.wTqoXj -h martin 25166 0.0 0.1 214696 19412 ? Ss 19:59 0:00 postgres: checkpointer martin 25167 0.0 0.0 214700 9152 ? Ss 19:59 0:00 postgres: background writer martin 25168 0.0 0.0 214568 9496 ? Ss 19:59 0:00 postgres: walwriter martin 25169 0.0 0.0 214976 6508 ? Ss 19:59 0:00 postgres: autovacuum launcher martin 25170 0.0 0.0 69616 5108 ? Ss 19:59 0:00 postgres: stats collector martin 25171 0.0 0.0 214968 6484 ? Ss 19:59 0:00 postgres: logical replication launcher martin 25781 0.0 0.0 8236 924 pts/3 S+ 20:10 0:00 grep postgres So it appears to me that this could be somewhat an intended feature or option of PostgreSQL: If it does not tear down *all* of the processes it can more quickly be started again. However that is still all just guess work until I take the time to dig deeper in how PostgreSQL handles stopping the database. I'd somehow still expect that it would remove all processes.
Thanks for the logs, both of you. Indeed it appears that Akonadi mistakenly thinks, that Postgres is no longer running. Do you guys use non-english locale by default? Could you please run the following command both when Postgres IS running and when it is NOT running, and paste its output here? pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data
Created attachment 120932 [details] akonadiserver.error with english locale, PostgreSQL properly shut down (In reply to Daniel Vrátil from comment #17) > Thanks for the logs, both of you. Indeed it appears that Akonadi mistakenly > thinks, that Postgres is no longer running. > > Do you guys use non-english locale by default? Yes: % locale LANG=de_DE.UTF-8 LANGUAGE=de LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL= > Could you please run the following command both when Postgres IS running and > when it is NOT running, and paste its output here? > > pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data Running: LANG=en /usr/lib/postgresql/11/bin/pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data pg_ctl: server is running (PID: 25164) /usr/lib/postgresql/11/bin/postgres "-D" "/home/martin/.local/share/akonadi/db_data" "-k/tmp/akonadi-martin.wTqoXj" "-h" "" with my locale: % /usr/lib/postgresql/11/bin/pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data pg_ctl: Server läuft (PID: 25164) /usr/lib/postgresql/11/bin/postgres "-D" "/home/martin/.local/share/akonadi/db_data" "-k/tmp/akonadi-martin.wTqoXj" "-h" "" After akonadictl stop: % LANG=en /usr/lib/postgresql/11/bin/pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data pg_ctl: server is running (PID: 25164) /usr/lib/postgresql/11/bin/postgres "-D" "/home/martin/.local/share/akonadi/db_data" "-k/tmp/akonadi-martin.wTqoXj" "-h" "" with my locale same as above. Stopped PostgreSQL process manually: % LANG=en /usr/lib/postgresql/11/bin/pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data pg_ctl: no server running % /usr/lib/postgresql/11/bin/pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data pg_ctl: kein Server läuft Test with US english locale: % locale LANG=en LANGUAGE=en LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=en_US.UTF-8 % akonadictl --verbose start % akonadictl stop Works. Stops database process just fine. akonadiserver.error attached. Well Daniel, fix would be easy I bet: Just start external commend with English locale if you need to parse strings in the output. Is there no better way than than parsing output? pg_ctl returns 3 as exit code if server is not running (see pg_ctl (1)): status mode checks whether a server is running in the specified data directory. If it is, the server's PID and the command line options that were used to invoke it are displayed. If the server is not running, pg_ctl returns an exit status of 3. If an accessible data directory is not specified, pg_ctl returns an exit status of 4.
(In reply to Daniel Vrátil from comment #17) > Do you guys use non-english locale by default? Same result on my end as for Martin
Git commit 565700f7fc1d73e337600109867fc01cc647cf13 by Daniel Vrátil. Committed on 20/06/2019 at 09:51. Pushed by dvratil into branch 'Applications/19.04'. Check Postgres status by checking return code of pg_ctl Summary: The current code which was checking the standard output of "pg_ctl status", doesn't work with non-English locale, causing Akonadi to leave Postgres running after shutdown, because it thinks the db is no longer running. FIXED-IN: 5.11.3 Reviewers: #kde_pim, mlaurent Reviewed By: #kde_pim, mlaurent Subscribers: mlaurent, kde-pim Tags: #kde_pim Differential Revision: https://phabricator.kde.org/D21871 M +2 -2 src/server/storage/dbconfigpostgresql.cpp https://commits.kde.org/akonadi/565700f7fc1d73e337600109867fc01cc647cf13
Dan, thank you very much! I appreciate your work on Akonadi & KDEPIM!