Your message dated Mon, 13 Apr 2015 12:24:31 +0200
with message-id <[email protected]>
and subject line Re: Bug#759725: #759725: postgresql-common: non-synchronous
service postgresql start/stop/reload
has caused the Debian Bug report #759725,
regarding postgresql-common: non-synchronous service postgresql
start/stop/reload
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
759725: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759725
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: postgresql-common
Version: 160
Severity: important
Hi,
When working on the FusionForge installation system today I noticed
that in Debian Jessie, running:
service postgresql start
(or stop, or reload), is now asynchronous, due to using the new
PostgreSQL systemd init scripts.
Previously I could rely on the init script to come back when the
database was properly stopped and flushed. Right now the command
returns immediately and starts/stops/reloads in the background.
My scripts need to modify the PostgreSQL listen address and reload it
before populating the database through the PHP application. They also
need to stop/backup/start the server for quick load/restore during our
testsuite. Due to this change the installation system fails randomly
due to race condition.
I found it basically impossible to work-around this issue in a
portable manner:
- 'service postgresql status' is not reliable: it usually says the
service is stopped far before the shutdown is complete. I also got a
few cases where it reported active service with no running daemon.
- the 'postgresql' process may be stopped already, but pg_ctl still
doing a faststop (especially when there's data to flush to disk) -
there may also be other PostgreSQL processes I don't know about;
so 'ps' is not reliable either.
- the postgresql control commands vary between Debian and RedHat
(pg_ctl vs. pg_clusterctl), and they need a data directory that can
be in varied, possibly multiple, locations. Using 'pg_*ctl' manually
is error-prone and long.
- in any case that will require fare more code and testing than
'service postgresql xxx'
Please consider maintaining 'service postgresql start/stop/reload'
synchronous even with systemd.
Cheers!
Sylvain
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=eo.UTF-8, LC_CTYPE=eo.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages postgresql-common depends on:
ii adduser 3.113+nmu3
ii debconf [debconf-2.0] 1.5.53
ii init-system-helpers 1.21
ii lsb-base 4.1+Debian13
ii postgresql-client-common 160
ii procps 1:3.3.9-7
ii ssl-cert 1.0.34
ii ucf 3.0030
Versions of packages postgresql-common recommends:
ii logrotate 3.8.7-1
postgresql-common suggests no packages.
-- debconf information excluded
--- End Message ---
--- Begin Message ---
Re: [email protected] 2015-04-08 <[email protected]>
> Here's my patch:
> rm -f /lib/systemd/system/postgresql*
> and fallback to init.d/.
>
> Package worked perfectly fine until systemd was introduced in it.
>
> Please apply.
I don't know what to say.
Christoph
--
[email protected] | http://www.df7cb.de/
--- End Message ---
_______________________________________________
Pkg-postgresql-public mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public
