Required after e17844c946 which
enabled graceful shutdown of workers, including the cron worker.
The latter may typically be busy on long-running tasks that
will not be aborted by a simple graceful shutdown request.
A typical shutdown sequence initiated by a daemon manager such
as start-stop-daemon will involve multiple SIGTERM signals to
ensure the process really stops in a timely manner.
This was not possible after e17844c946
if any cron worker was busy.
This does not allow to use a database with unicode to run openerp but does not fail (was getting an empty list of existing databases)
bzr revid: mat@openerp.com-20140214144444-0tjcz14rhlw94i50
The various pg_* utilities require the password
via a special environment variable or a special
`pgpass` file in the user home, even on Unix,
namely when the PostgreSQL connection is done
via TCP and not via a unix socket.
Setting the environment variable is relatively
safe if it is removed from the environment
immediately after the operation, and saves user
the trouble of managing the pgpass file themselves.
This had been fixed at revision 3992 but was
incorrectly removed for non win32 platforms
at revision 4424 (rev-id stw@openerp.com-20120912114651-8hcliparft1ep9tc)
lp bug: https://launchpad.net/bugs/790164 fixed
lp bug: https://launchpad.net/bugs/919100 fixed
bzr revid: odo@openerp.com-20130313152020-suo2pyrabae0ecg4
The setting/clearing of the tracking were not done
consistently, causing log messages that appeared
to come from one database while coming from another
one or none at all.
The tracker is now set at the earliest points
of request handling where we can:
- in web client, when creating WebRequests (dbname, uid)
- at RPC dispatching in server (uid)
- at cron job acquisition in CronWorker (dbname)
- at Registry acquisition in RegistryManager (dbname)
The tracker is cleared at the very entrance of
the request in the WSGI `application`, ensuring
that no logging is produced with an obsolete
db name. (It cannot be cleared at the end of
the request handling because the werkzeug
wrapper outputs more logging afterwards)
bzr revid: odo@openerp.com-20130301120744-jfitcmze2jldecod
* We have to wait for complete service stop before trying to re-start
OpenERP service, otherwise service manager will complain that the
service is already running - and thus preventing to it start.
'sc' command only send a query to service manager without waiting
for completion - instead we use 'net' command which wait for complete
start/stop operation.
bzr revid: xal@openerp.com-20130107162302-xtf44nm10859203w
The pooljobs and scheduled_cron_jobs stuff was only used to
delay the processing of cron jobs until after the registry
was fully loaded. However this is already the case because
RegistryManager.new() only sets the flag at the end of the
init step.
The flag was named `registry.cron` but simply meant that the
registry was fully loaded and ready, so it is simpler to
rename it to `registry.ready`.
In multiprocess mode this flag is enterily irrelevant
so there is no need to selectively set it to True or
False. `registry.ready` is simpler.
bzr revid: odo@openerp.com-20121221133751-h4x670vblfr3d09e
Nota: If we replace sequence signaling for cache invalidation with pg
listen/notify in the future, we will use the same mechanism for more accurate
cron timing.
bzr revid: al@openerp.com-20121209170447-zs0k3jazokylwvar