Bug 337951 - The postgres process doesn't stop with Akonadi
Summary: The postgres process doesn't stop with Akonadi
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: GIT (master)
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-01 08:07 UTC by Christophe Marin
Modified: 2017-01-07 22:08 UTC (History)
1 user (show)

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 Christophe Marin 2014-08-01 08:07:40 UTC
Using master from 4 days ago (currently at fd7adf7) and using the psql backend

Something unusual appeared a couple weeks ago. After running akonadictl stop, the psql server doesn't stop.

I've cleaned my tmp dir, restarted the machine and looked at what happens:

# ls -l /tmp 
total 0
drwxr-xr-x 1 krop krop  62 août   1 09:46 akonadi-krop.FW8sFp
drwx------ 1 krop krop  40 août   1 09:46 akonadi-krop.o6TLY9

and

# ll /tmp/akonadi-krop.FW8sFp 
total 0
# ll /tmp/akonadi-krop.o6TLY9 
total 0
srwxr-xr-x 1 krop krop 0 août   1 09:46 akonadiserver.socket


/home/krop/.local/share/akonadi/socket-$HOSTNAME points to the correct dir

# ps x |grep postgres
 3673 ?        S      0:00 /usr/lib/postgresql93/bin/postgres -D /home/krop/.local/share/akonadi/db_data -k/tmp/akonadi-krop.FW8sFp -h

The command line indicates that this tmp dir should contain the psql socket but it's empty.

Now, after running akonadictl stop, the postgres processes are still there (minus the workers) and

# ls -al /tmp/akonadi-krop.FW8sFp

srwxrwxrwx 1 krop krop   0 août   1 09:46 .s.PGSQL.5432
-rw------- 1 krop krop  86 août   1 09:46 .s.PGSQL.5432.lock

Now the postgres lock & socket files are also there.

# cat /tmp/akonadi-krop.FW8sFp/.s.PGSQL.5432.lock 
3673
/home/krop/.local/share/akonadi/db_data
1406879212
5432
/tmp/akonadi-krop.FW8sFp
Comment 1 Daniel Vrátil 2014-08-05 13:58:59 UTC
This can happen with MySQL too. It happens when Akonadi is busy with some operations when you shut it down - akonadi_control will just kill the akonadiserver process after some waiting, so it's possible that akonadiserver never gets to shut down the database.

We probably need a mechanism within akonadiserver to be able to abort running tasks and proceed to shut down as quickly as possible.
Comment 2 Denis Kurz 2016-09-24 20:45:37 UTC
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 3 Denis Kurz 2017-01-07 22:08:26 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.