buildbot scheduler not working - scheduler

I have essentially the same problem discussed here buildbot scheduler not work, but the answer there may not apply -- possibly because I've got a newer version of buildbot
>buildbot --version
Buildbot version: 0.8.12
Twisted version: 16.2.0
running on Windows 7 64-bit.
I'd like an svn commit to trigger the buildbot builders, but instead, only the Periodic scheduler (when enabled) triggers the builders. The log shows
2016-06-10 11:40:18-0700 [-] SVNPoller: polling
2016-06-10 11:40:18-0700 [-] SVNPoller: svnurl=file:///G:/buildbot/buildbot_repo/trunk/triggers_for_testing, root=file:///G:/buildbot/buildbot_repo, so prefix=trunk/triggers_for_testing
2016-06-10 11:40:18-0700 [-] SVNPoller: starting at change 31
2016-06-10 11:40:18-0700 [-] SVNPoller: _process_changes None .. 31
2016-06-10 11:40:18-0700 [-] SVNPoller: finished polling None
2016-06-10 11:40:38-0700 [-] SVNPoller: polling
2016-06-10 11:40:38-0700 [-] SVNPoller: _process_changes 31 .. 32
2016-06-10 11:40:38-0700 [-] Adding change revision 32
2016-06-10 11:40:38-0700 [-] SVNPoller: finished polling None
But the scheduler does not trigger the builders.
The answer at the above cited question says the log should include entries "added change Change(..." if the SVNPoller is working, and then advises what to look for within those entries. My log does not include any such entries.
Below are a snip of the master.cfg and (tail of) twistd.log files.
Any help most appreciated.
snip of master.cfg:
# -*- python -*-
# ex: set syntax=python:
_test_buildbot = False # Set to True to use configuration settings that facilicate testing
_poll_test_repository = True # Set to True to enable testing of an SVNPoller and SingleBranchScheduler monitoring the local repository "file:///G:/buildbot/buildbot_repo/trunk/triggers_for_testing".
_hypersensitive_SVNPoller = True # Set to True to facilicate testing of the SVNPoller and SingleBranchScheduler, making them poll frequently and look for changes *anywhere*.
# This is a sample buildmaster config file. It must be installed as
# 'master.cfg' in your buildmaster's base directory.
# This is the dictionary that the buildmaster pays attention to. We also use
# a shorter alias to save typing.
c = BuildmasterConfig = {}
####### STEPS
<SNIPPED...>
####### BUILDSLAVES
from buildbot import buildslave
from buildbot.schedulers.basic import SingleBranchScheduler
from buildbot.changes import filter
# The 'slaves' list defines the set of recognized buildslaves. Each element is
# a BuildSlave object, specifying a unique slave name and password. The same
# slave name and password must be configured on the slave.
c['slaves'] = [ buildslave.BuildSlave("win64-worker", "pass"),
buildslave.BuildSlave("centos7-worker", "pass"),
]
# 'protocols' contains information about protocols which master will use for
# communicating with slaves.
# You must define at least 'port' option that slaves could connect to your master
# with this protocol.
# 'port' must match the value configured into the buildslaves (with their
# --master option)
c['protocols'] = {'pb': {'port': 9989}}
####### SCHEDULERS
from buildbot.schedulers.timed import Periodic
# Configure the Schedulers, which decide how to react to incoming changes. In this
# case, just kick off a 'ifort_win32_build', 'ifort_win64_build', gfortran_win64_build, and gfortran_centos7_build builds
# define the dynamic scheduler
trunk_sf_codechanged = SingleBranchScheduler(name = "trunk_sf_codechanged",
change_filter = filter.ChangeFilter(
repository = "svn://kraken",
branch = None if _hypersensitive_SVNPoller else "trunk/sf_code",
),
treeStableTimer = 1 * 30 if _test_buildbot else 10 * 60,
builderNames = ["ifort_win32_build",
"ifort_win64_build",
"gfortran_win64_build",
"gfortran_centos7_build",
],
)
triggers_for_testing_changed = SingleBranchScheduler(name = "test_triggers_changed",
change_filter = filter.ChangeFilter(
repository = "file:///G:/buildbot/buildbot_repo/trunk/triggers_for_testing",
branch = None,
),
treeStableTimer = 1 * 20,
builderNames = ["ifort_win32_build",
"ifort_win64_build",
"gfortran_win64_build",
"gfortran_centos7_build",
],
)
# define the periodic scheduler
periodicscheduler = Periodic(name = "Every 4 Days",
builderNames = ["ifort_win32_build",
"ifort_win64_build",
"gfortran_win64_build",
"gfortran_centos7_build",
],
periodicBuildTimer = 10*60 if _test_buildbot else 4*24*60*60,
)
# define the available schedulers
c['schedulers'] = [
trunk_sf_codechanged,
]
if _poll_test_repository:
c['schedulers'].append(triggers_for_testing_changed)
if _test_buildbot:
c['schedulers'].append(periodicscheduler)
####### CHANGESOURCES
from buildbot.changes.svnpoller import SVNPoller, split_file_branches
from twisted.python import log
# the 'change_source' setting tells the buildmaster how it should find out
# about source code changes.
svn_nwra_mry_poller = SVNPoller(svnurl = "svn://kraken" if _hypersensitive_SVNPoller else "svn://kraken/trunk/sf_code",
svnuser = "buildbot",
svnpasswd = "buildbot",
svnbin = 'C:/Program Files/TortoiseSVN/bin/svn.exe',
pollinterval = 1 * 20 if _test_buildbot else 10 * 60,
split_file = split_file_branches)
test_trigger_poller = SVNPoller(svnurl = "file:///G:/buildbot/buildbot_repo/trunk/triggers_for_testing",
svnuser = "buildbot",
svnpasswd = "buildbot",
svnbin = 'C:/Program Files/TortoiseSVN/bin/svn.exe',
pollinterval = 1 * 20,
split_file = split_file_branches)
c['change_source'] = [
svn_nwra_mry_poller,
]
if _poll_test_repository:
c['change_source'].append(test_trigger_poller)
<SNIPPED...>
tail of twistd.log:
2016-06-10 10:39:26-0700 [-] BuildMaster is running
2016-06-10 10:39:26-0700 [-] Main loop terminated.
2016-06-10 10:39:26-0700 [-] Server Shut Down.
2016-06-10 10:39:26-0700 [-] Server Shut Down.
2016-06-10 11:33:48-0700 [-] Loading buildbot.tac...
2016-06-10 11:33:48-0700 [-] Loaded.
2016-06-10 11:33:48-0700 [-] twistd 16.2.0 (C:\Users\buildbot\AppData\Local\Programs\WinPython-64bit-2.7.10.3\python-2.7.10.amd64\python.exe 2.7.10) starting up.
2016-06-10 11:33:48-0700 [-] reactor class: twisted.internet.selectreactor.SelectReactor.
2016-06-10 11:33:48-0700 [-] Starting BuildMaster -- buildbot.version: 0.8.12
2016-06-10 11:33:48-0700 [-] Loading configuration from 'G:\\buildbot\\master\\master.cfg'
2016-06-10 11:33:49-0700 [-] Setting up database with URL 'sqlite:///state.sqlite'
2016-06-10 11:33:49-0700 [-] setting database journal mode to 'wal'
2016-06-10 11:33:49-0700 [-] Using SQLite Version (3, 6, 21)
2016-06-10 11:33:49-0700 [-] NOTE: this old version of SQLite does not support WAL journal mode; a busy master may encounter 'Database is locked' errors. Consider upgrading.
2016-06-10 11:33:49-0700 [-] adding 2 new changesources, removing 0
2016-06-10 11:33:49-0700 [-] adding 2 new slaves, removing 0
2016-06-10 11:33:49-0700 [-] adding 4 new builders, removing 0
2016-06-10 11:33:49-0700 [-] trying to load status pickle from G:\buildbot\master\ifort_win32_build\builder
2016-06-10 11:33:49-0700 [-] added builder ifort_win32_build with tags None
2016-06-10 11:33:49-0700 [-] trying to load status pickle from G:\buildbot\master\gfortran_win64_build\builder
2016-06-10 11:33:49-0700 [-] added builder gfortran_win64_build with tags None
2016-06-10 11:33:49-0700 [-] trying to load status pickle from G:\buildbot\master\gfortran_centos7_build\builder
2016-06-10 11:33:49-0700 [-] added builder gfortran_centos7_build with tags None
2016-06-10 11:33:49-0700 [-] trying to load status pickle from G:\buildbot\master\ifort_win64_build\builder
2016-06-10 11:33:49-0700 [-] added builder ifort_win64_build with tags None
2016-06-10 11:33:49-0700 [-] PBServerFactory starting on 9989
2016-06-10 11:33:49-0700 [-] Starting factory <twisted.spread.pb.PBServerFactory instance at 0x00000000056AF508>
2016-06-10 11:33:49-0700 [-] adding scheduler 'test_triggers_changed'
2016-06-10 11:33:49-0700 [-] adding scheduler 'trunk_sf_codechanged'
2016-06-10 11:33:49-0700 [-] WebStatus using (G:\buildbot\master\public_html)
2016-06-10 11:33:49-0700 [-] RotateLogSite starting on 8010
2016-06-10 11:33:49-0700 [-] Starting factory <buildbot.status.web.baseweb.RotateLogSite instance at 0x0000000005711208>
2016-06-10 11:33:49-0700 [-] Setting up http.log rotating 10 files of 10000000 bytes each
2016-06-10 11:33:49-0700 [-] BuildMaster is running
2016-06-10 11:34:09-0700 [-] SVNPoller: polling
2016-06-10 11:34:09-0700 [-] SVNPoller: svnurl=file:///G:/buildbot/buildbot_repo/trunk/triggers_for_testing, root=file:///G:/buildbot/buildbot_repo, so prefix=trunk/triggers_for_testing
2016-06-10 11:34:09-0700 [-] SVNPoller: starting at change 30
2016-06-10 11:34:09-0700 [-] SVNPoller: _process_changes None .. 30
2016-06-10 11:34:09-0700 [-] SVNPoller: finished polling None
2016-06-10 11:34:29-0700 [Broker,0,192.168.77.222] slave 'centos7-worker' attaching from IPv4Address(TCP, '192.168.77.222', 53458)
2016-06-10 11:34:29-0700 [Broker,0,192.168.77.222] Got slaveinfo from 'centos7-worker'
2016-06-10 11:34:29-0700 [Broker,0,192.168.77.222] Starting buildslave keepalive timer for 'centos7-worker'
2016-06-10 11:34:29-0700 [Broker,0,192.168.77.222] bot attached
2016-06-10 11:34:29-0700 [Broker,0,192.168.77.222] Buildslave centos7-worker attached to gfortran_centos7_build
2016-06-10 11:34:29-0700 [-] SVNPoller: polling
2016-06-10 11:34:29-0700 [-] SVNPoller: no changes
2016-06-10 11:34:29-0700 [-] SVNPoller: _process_changes 30 .. 30
2016-06-10 11:34:29-0700 [-] SVNPoller: finished polling None
2016-06-10 11:34:49-0700 [-] SVNPoller: polling
2016-06-10 11:34:49-0700 [-] SVNPoller: no changes
2016-06-10 11:34:49-0700 [-] SVNPoller: _process_changes 30 .. 30
2016-06-10 11:34:49-0700 [-] SVNPoller: finished polling None
2016-06-10 11:35:09-0700 [-] SVNPoller: polling
2016-06-10 11:35:09-0700 [-] SVNPoller: _process_changes 30 .. 31
2016-06-10 11:35:09-0700 [-] Adding change revision 31
2016-06-10 11:35:09-0700 [-] SVNPoller: finished polling None
2016-06-10 11:35:26-0700 [Broker,1,169.254.203.227] slave 'win64-worker' attaching from IPv4Address(TCP, '169.254.203.227', 53461)
2016-06-10 11:35:26-0700 [Broker,1,169.254.203.227] Got slaveinfo from 'win64-worker'
2016-06-10 11:35:26-0700 [Broker,1,169.254.203.227] Starting buildslave keepalive timer for 'win64-worker'
2016-06-10 11:35:26-0700 [Broker,1,169.254.203.227] bot attached
2016-06-10 11:35:26-0700 [Broker,1,169.254.203.227] Buildslave win64-worker attached to ifort_win32_build
2016-06-10 11:35:26-0700 [Broker,1,169.254.203.227] Buildslave win64-worker attached to gfortran_win64_build
2016-06-10 11:35:26-0700 [Broker,1,169.254.203.227] Buildslave win64-worker attached to ifort_win64_build
2016-06-10 11:35:29-0700 [-] SVNPoller: polling
2016-06-10 11:35:29-0700 [-] SVNPoller: no changes
2016-06-10 11:35:29-0700 [-] SVNPoller: _process_changes 31 .. 31
2016-06-10 11:35:29-0700 [-] SVNPoller: finished polling None
2016-06-10 11:35:49-0700 [-] SVNPoller: polling
2016-06-10 11:35:49-0700 [-] SVNPoller: no changes
2016-06-10 11:35:49-0700 [-] SVNPoller: _process_changes 31 .. 31
2016-06-10 11:35:49-0700 [-] SVNPoller: finished polling None
2016-06-10 11:36:09-0700 [-] SVNPoller: polling
2016-06-10 11:36:09-0700 [-] SVNPoller: no changes
2016-06-10 11:36:09-0700 [-] SVNPoller: _process_changes 31 .. 31
2016-06-10 11:36:09-0700 [-] SVNPoller: finished polling None
2016-06-10 11:36:29-0700 [-] SVNPoller: polling
2016-06-10 11:36:29-0700 [-] SVNPoller: no changes
2016-06-10 11:36:29-0700 [-] SVNPoller: _process_changes 31 .. 31
2016-06-10 11:36:29-0700 [-] SVNPoller: finished polling None
2016-06-10 11:36:49-0700 [-] SVNPoller: polling
2016-06-10 11:36:49-0700 [-] SVNPoller: no changes
2016-06-10 11:36:49-0700 [-] SVNPoller: _process_changes 31 .. 31
2016-06-10 11:36:49-0700 [-] SVNPoller: finished polling None
2016-06-10 11:37:09-0700 [-] SVNPoller: polling
2016-06-10 11:37:09-0700 [-] SVNPoller: no changes
2016-06-10 11:37:09-0700 [-] SVNPoller: _process_changes 31 .. 31
2016-06-10 11:37:09-0700 [-] SVNPoller: finished polling None
2016-06-10 11:37:29-0700 [-] SVNPoller: polling
2016-06-10 11:37:29-0700 [-] SVNPoller: no changes
2016-06-10 11:37:29-0700 [-] SVNPoller: _process_changes 31 .. 31
2016-06-10 11:37:29-0700 [-] SVNPoller: finished polling None
2016-06-10 11:37:49-0700 [-] SVNPoller: polling
2016-06-10 11:37:49-0700 [-] SVNPoller: no changes
2016-06-10 11:37:49-0700 [-] SVNPoller: _process_changes 31 .. 31
2016-06-10 11:37:49-0700 [-] SVNPoller: finished polling None
2016-06-10 11:38:09-0700 [-] SVNPoller: polling
2016-06-10 11:38:09-0700 [-] SVNPoller: no changes
2016-06-10 11:38:09-0700 [-] SVNPoller: _process_changes 31 .. 31
2016-06-10 11:38:09-0700 [-] SVNPoller: finished polling None
2016-06-10 11:38:29-0700 [-] SVNPoller: polling
2016-06-10 11:38:29-0700 [-] SVNPoller: no changes
2016-06-10 11:38:29-0700 [-] SVNPoller: _process_changes 31 .. 31
2016-06-10 11:38:29-0700 [-] SVNPoller: finished polling None
2016-06-10 11:38:32-0700 [-] Received SIGINT, shutting down.
2016-06-10 11:38:32-0700 [-] (TCP Port 8010 Closed)
2016-06-10 11:38:32-0700 [-] Stopping factory <buildbot.status.web.baseweb.RotateLogSite instance at 0x0000000005711208>
2016-06-10 11:38:32-0700 [Broker,0,192.168.77.222] BuildSlave.detached(centos7-worker)
2016-06-10 11:38:32-0700 [Broker,0,192.168.77.222] releaseLocks(<BuildSlave 'centos7-worker'>): []
2016-06-10 11:38:32-0700 [Broker,0,192.168.77.222] Buildslave centos7-worker detached from gfortran_centos7_build
2016-06-10 11:38:32-0700 [Broker,1,169.254.203.227] BuildSlave.detached(win64-worker)
2016-06-10 11:38:32-0700 [Broker,1,169.254.203.227] releaseLocks(<BuildSlave 'win64-worker'>): []
2016-06-10 11:38:32-0700 [Broker,1,169.254.203.227] Buildslave win64-worker detached from ifort_win32_build
2016-06-10 11:38:32-0700 [Broker,1,169.254.203.227] Buildslave win64-worker detached from gfortran_win64_build
2016-06-10 11:38:32-0700 [Broker,1,169.254.203.227] Buildslave win64-worker detached from ifort_win64_build
2016-06-10 11:38:32-0700 [-] (TCP Port 9989 Closed)
2016-06-10 11:38:32-0700 [-] Stopping factory <twisted.spread.pb.PBServerFactory instance at 0x00000000056AF508>
2016-06-10 11:38:32-0700 [-] Main loop terminated.
2016-06-10 11:38:32-0700 [-] Server Shut Down.
2016-06-10 11:38:32-0700 [-] Server Shut Down.
2016-06-10 11:39:56-0700 [-] Loading buildbot.tac...
2016-06-10 11:39:57-0700 [-] Loaded.
2016-06-10 11:39:57-0700 [-] twistd 16.2.0 (C:\Users\buildbot\AppData\Local\Programs\WinPython-64bit-2.7.10.3\python-2.7.10.amd64\python.exe 2.7.10) starting up.
2016-06-10 11:39:57-0700 [-] reactor class: twisted.internet.selectreactor.SelectReactor.
2016-06-10 11:39:57-0700 [-] Starting BuildMaster -- buildbot.version: 0.8.12
2016-06-10 11:39:57-0700 [-] Loading configuration from 'G:\\buildbot\\master\\master.cfg'
2016-06-10 11:39:57-0700 [-] Setting up database with URL 'sqlite:///state.sqlite'
2016-06-10 11:39:57-0700 [-] setting database journal mode to 'wal'
2016-06-10 11:39:57-0700 [-] Using SQLite Version (3, 6, 21)
2016-06-10 11:39:57-0700 [-] NOTE: this old version of SQLite does not support WAL journal mode; a busy master may encounter 'Database is locked' errors. Consider upgrading.
2016-06-10 11:39:58-0700 [-] adding 2 new changesources, removing 0
2016-06-10 11:39:58-0700 [-] adding 2 new slaves, removing 0
2016-06-10 11:39:58-0700 [-] adding 4 new builders, removing 0
2016-06-10 11:39:58-0700 [-] trying to load status pickle from G:\buildbot\master\ifort_win32_build\builder
2016-06-10 11:39:58-0700 [-] added builder ifort_win32_build with tags None
2016-06-10 11:39:58-0700 [-] trying to load status pickle from G:\buildbot\master\gfortran_win64_build\builder
2016-06-10 11:39:58-0700 [-] added builder gfortran_win64_build with tags None
2016-06-10 11:39:58-0700 [-] trying to load status pickle from G:\buildbot\master\gfortran_centos7_build\builder
2016-06-10 11:39:58-0700 [-] added builder gfortran_centos7_build with tags None
2016-06-10 11:39:58-0700 [-] trying to load status pickle from G:\buildbot\master\ifort_win64_build\builder
2016-06-10 11:39:58-0700 [-] added builder ifort_win64_build with tags None
2016-06-10 11:39:58-0700 [-] PBServerFactory starting on 9989
2016-06-10 11:39:58-0700 [-] Starting factory <twisted.spread.pb.PBServerFactory instance at 0x000000000575E8C8>
2016-06-10 11:39:58-0700 [-] adding scheduler 'test_triggers_changed'
2016-06-10 11:39:58-0700 [-] adding scheduler 'trunk_sf_codechanged'
2016-06-10 11:39:58-0700 [-] WebStatus using (G:\buildbot\master\public_html)
2016-06-10 11:39:58-0700 [-] RotateLogSite starting on 8010
2016-06-10 11:39:58-0700 [-] Starting factory <buildbot.status.web.baseweb.RotateLogSite instance at 0x00000000057BB0C8>
2016-06-10 11:39:58-0700 [-] Setting up http.log rotating 10 files of 10000000 bytes each
2016-06-10 11:39:58-0700 [-] BuildMaster is running
2016-06-10 11:40:03-0700 [Broker,0,169.254.203.227] slave 'win64-worker' attaching from IPv4Address(TCP, '169.254.203.227', 53479)
2016-06-10 11:40:03-0700 [Broker,0,169.254.203.227] Got slaveinfo from 'win64-worker'
2016-06-10 11:40:03-0700 [Broker,0,169.254.203.227] Starting buildslave keepalive timer for 'win64-worker'
2016-06-10 11:40:03-0700 [Broker,0,169.254.203.227] bot attached
2016-06-10 11:40:03-0700 [Broker,0,169.254.203.227] Buildslave win64-worker attached to ifort_win32_build
2016-06-10 11:40:03-0700 [Broker,0,169.254.203.227] Buildslave win64-worker attached to gfortran_win64_build
2016-06-10 11:40:03-0700 [Broker,0,169.254.203.227] Buildslave win64-worker attached to ifort_win64_build
2016-06-10 11:40:05-0700 [Broker,1,192.168.77.222] slave 'centos7-worker' attaching from IPv4Address(TCP, '192.168.77.222', 53480)
2016-06-10 11:40:05-0700 [Broker,1,192.168.77.222] Got slaveinfo from 'centos7-worker'
2016-06-10 11:40:05-0700 [Broker,1,192.168.77.222] Starting buildslave keepalive timer for 'centos7-worker'
2016-06-10 11:40:05-0700 [Broker,1,192.168.77.222] bot attached
2016-06-10 11:40:05-0700 [Broker,1,192.168.77.222] Buildslave centos7-worker attached to gfortran_centos7_build
2016-06-10 11:40:18-0700 [-] SVNPoller: polling
2016-06-10 11:40:18-0700 [-] SVNPoller: svnurl=file:///G:/buildbot/buildbot_repo/trunk/triggers_for_testing, root=file:///G:/buildbot/buildbot_repo, so prefix=trunk/triggers_for_testing
2016-06-10 11:40:18-0700 [-] SVNPoller: starting at change 31
2016-06-10 11:40:18-0700 [-] SVNPoller: _process_changes None .. 31
2016-06-10 11:40:18-0700 [-] SVNPoller: finished polling None
2016-06-10 11:40:38-0700 [-] SVNPoller: polling
2016-06-10 11:40:38-0700 [-] SVNPoller: _process_changes 31 .. 32
2016-06-10 11:40:38-0700 [-] Adding change revision 32
2016-06-10 11:40:38-0700 [-] SVNPoller: finished polling None
2016-06-10 11:40:58-0700 [-] SVNPoller: polling
2016-06-10 11:40:58-0700 [-] SVNPoller: no changes
2016-06-10 11:40:58-0700 [-] SVNPoller: _process_changes 32 .. 32
2016-06-10 11:40:58-0700 [-] SVNPoller: finished polling None
2016-06-10 11:41:18-0700 [-] SVNPoller: polling
2016-06-10 11:41:18-0700 [-] SVNPoller: no changes
2016-06-10 11:41:18-0700 [-] SVNPoller: _process_changes 32 .. 32
2016-06-10 11:41:18-0700 [-] SVNPoller: finished polling None
2016-06-10 11:41:38-0700 [-] SVNPoller: polling

I managed to solve this problem by deleting altogether the
split_file = split_file_branches
argument to the two SVNPoller constructors. It seems the split_file is not necessary for polling a single branch in a repository organized as mine.

Related

psycopg2 failed to connect abruptly while it worked yesterday

I'm working on deploying my flask application on Nginx with Gunicorn and as of yesterday I was able to access my website on a remote device and run queries that affected the database but for some reason today it has abruptly stopped and I get the following error in the log file.
Connection._handle_dbapi_exception_noconnection(
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/engine/base.py", line 2117, in
_handle_dbapi_exception_noconnection
util.raise_(
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/util/compat.py", line 207, in raise_
raise exception
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/engine/base.py", line 3280, in _wrap_pool_connect
return fn()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/pool/base.py", line 310, in connect
return _ConnectionFairy._checkout(self)
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/pool/base.py", line 868, in _checkout
fairy = _ConnectionRecord.checkout(pool)
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/pool/base.py", line 476, in checkout
rec = pool._do_get()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/pool/impl.py", line 146, in _do_get
self._dec_overflow()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
compat.raise_(
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/util/compat.py", line 207, in raise_
raise exception
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/pool/impl.py", line 143, in _do_get
return self._create_connection()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/pool/base.py", line 256, in _create_connection
return _ConnectionRecord(self)
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/pool/base.py", line 371, in __init__
self.__connect()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/pool/base.py", line 666, in __connect
pool.logger.debug("Error on connect(): %s", e)
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
compat.raise_(
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/util/compat.py", line 207, in raise_
raise exception
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/pool/base.py", line 661, in __connect
self.dbapi_connection = connection = pool._invoke_creator(self)
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/engine/create.py", line 590, in connect
return dialect.connect(*cargs, **cparams)
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/sqlalchemy/engine/default.py", line 597, in connect
return self.dbapi.connect(*cargs, **cparams)
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/psycopg2/__init__.py", line 122, in connect
conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at
"localhost" (127.0.0.1), port 5432 failed: FATAL: the database system is starting up
(Background on this error at: https://sqlalche.me/e/14/e3q8)
[2022-09-29 15:20:41 +0300] [29652] [INFO] Worker exiting (pid: 29652)
Traceback (most recent call last):
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/arbiter.py", line 209, in run
self.sleep()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/arbiter.py", line 357, in sleep
ready = select.select([self.PIPE[0]], [], [], 1.0)
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/arbiter.py", line 242, in handle_chld
self.reap_workers()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/arbiter.py", line 525, in reap_workers
raise HaltServer(reason, self.WORKER_BOOT_ERROR)
gunicorn.errors.HaltServer: <HaltServer 'Worker failed to boot.' 3>
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/bin/gunicorn", line 8,
in <module>
sys.exit(run())
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/app/wsgiapp.py", line 67, in run
WSGIApplication("%(prog)s [OPTIONS] [APP_MODULE]").run()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/app/base.py", line 231, in run
super().run()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/app/base.py", line 72, in run
Arbiter(self).run()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/arbiter.py", line 229, in run
self.halt(reason=inst.reason, exit_status=inst.exit_status)
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/arbiter.py", line 342, in halt
self.stop()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/arbiter.py", line 393, in stop
time.sleep(0.1)
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/arbiter.py", line 242, in handle_chld
self.reap_workers()
File "/home/dancungerald/Documents/Python/SCHEYE/scheye_venv/lib/python3.8/site-
packages/gunicorn/arbiter.py", line 525, in reap_workers
raise HaltServer(reason, self.WORKER_BOOT_ERROR)
gunicorn.errors.HaltServer: <HaltServer 'Worker failed to boot.' 3>
[2022-09-29 15:20:42 +0300] [29673] [INFO] Starting gunicorn 20.1.0
[2022-09-29 15:20:42 +0300] [29673] [INFO] Listening at: http://127.0.0.1:8000
(29673)
[2022-09-29 15:20:42 +0300] [29673] [INFO] Using worker: sync
[2022-09-29 15:20:42 +0300] [29675] [INFO] Booting worker with pid: 29675
[2022-09-29 15:20:42 +0300] [29676] [INFO] Booting worker with pid: 29676
[2022-09-29 15:20:42 +0300] [29677] [INFO] Booting worker with pid: 29677
[2022-09-29 15:20:42 +0300] [29678] [INFO] Booting worker with pid: 29678
[2022-09-29 15:20:42 +0300] [29679] [INFO] Booting worker with pid: 29679
[2022-09-29 15:20:42 +0300] [29680] [INFO] Booting worker with pid: 29680
[2022-09-29 15:20:42 +0300] [29681] [INFO] Booting worker with pid: 29681
[2022-09-29 15:20:43 +0300] [29682] [INFO] Booting worker with pid: 29682
[2022-09-29 15:20:43 +0300] [29683] [INFO] Booting worker with pid: 29683
[2022-09-29 15:46:12 +0300] [29682] [INFO] Worker exiting (pid: 29682)
[2022-09-29 15:46:12 +0300] [29681] [INFO] Worker exiting (pid: 29681)
[2022-09-29 15:46:12 +0300] [29683] [INFO] Worker exiting (pid: 29683)
[2022-09-29 15:46:12 +0300] [29679] [INFO] Worker exiting (pid: 29679)
[2022-09-29 15:46:12 +0300] [29678] [INFO] Worker exiting (pid: 29678)
[2022-09-29 15:46:12 +0300] [29677] [INFO] Worker exiting (pid: 29677)
[2022-09-29 15:46:12 +0300] [29680] [INFO] Worker exiting (pid: 29680)
[2022-09-29 15:46:12 +0300] [29675] [INFO] Worker exiting (pid: 29675)
[2022-09-29 15:46:12 +0300] [29676] [INFO] Worker exiting (pid: 29676)
[2022-09-29 15:46:12 +0300] [29673] [INFO] Handling signal: term
[2022-09-29 15:46:12 +0300] [29673] [WARNING] Worker with pid 29675 was terminated
due to signal 15
[2022-09-29 15:46:12 +0300] [29673] [WARNING] Worker with pid 29678 was terminated
due to signal 15
[2022-09-29 15:46:12 +0300] [29673] [WARNING] Worker with pid 29681 was terminated
due to signal 15
[2022-09-29 15:46:12 +0300] [29673] [WARNING] Worker with pid 29682 was terminated
due to signal 15
[2022-09-29 15:46:12 +0300] [29673] [WARNING] Worker with pid 29677 was terminated
due to signal 15
[2022-09-29 15:46:12 +0300] [29673] [WARNING] Worker with pid 29679 was terminated
due to signal 15
[2022-09-29 15:46:12 +0300] [29673] [WARNING] Worker with pid 29680 was terminated
due to signal 15
[2022-09-29 15:46:12 +0300] [29673] [WARNING] Worker with pid 29676 was terminated
due to signal 15
[2022-09-29 15:46:12 +0300] [29673] [WARNING] Worker with pid 29683 was terminated
due to signal 15
[2022-09-29 15:46:12 +0300] [29673] [INFO] Shutting down: Master
[2022-09-29 15:46:14 +0300] [30879] [INFO] Starting gunicorn 20.1.0
[2022-09-29 15:46:14 +0300] [30879] [INFO] Listening at: http://127.0.0.1:8000
(30879)
[2022-09-29 15:46:14 +0300] [30879] [INFO] Using worker: sync
[2022-09-29 15:46:14 +0300] [30881] [INFO] Booting worker with pid: 30881
[2022-09-29 15:46:14 +0300] [30882] [INFO] Booting worker with pid: 30882
[2022-09-29 15:46:14 +0300] [30883] [INFO] Booting worker with pid: 30883
[2022-09-29 15:46:14 +0300] [30884] [INFO] Booting worker with pid: 30884
[2022-09-29 15:46:14 +0300] [30885] [INFO] Booting worker with pid: 30885
[2022-09-29 15:46:14 +0300] [30886] [INFO] Booting worker with pid: 30886
[2022-09-29 15:46:14 +0300] [30887] [INFO] Booting worker with pid: 30887
[2022-09-29 15:46:14 +0300] [30888] [INFO] Booting worker with pid: 30888
[2022-09-29 15:46:14 +0300] [30889] [INFO] Booting worker with pid: 30889
It proposes that postgres is not running but I started the server and when I run netstat -pln |grep 5432 I see that postgres is running on port 5432 so I doubt it's anything to do with the database connection.
If it helps, when it worked I was operating on my home network/wifi but it failed when I ran it today on an institutional network/wifi.
I have no idea what transpired for the app to behave this way. Any help would be highly appreciated.
I enabled postgres to start up on boot with supervisord as per this website. Here's what my supervisor configuration file looked like:
[program:appName]
directory=/Project/File/Directory/appName
command=/Project/File/Location/appName/app_venv/bin/gunicorn -w 9 run:app
user=username
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
stderr_logfile=/var/log/appName/app.err.log
stdout_logfile=/var/log/appName/app.out.log
[program:postgresql]
user=postgres
command=/usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
redirect_stderr=true

vertica kafka scheduler stops processing messages

Could you please help me? I have vertica's scheduler, it reads data from apache kafka's topic. Periodically, the scheduler stops processing messages from the topic, there are no errors in the scheduler log, the scheduler process itself continues to work, but does not process messages and it cannot be stopped correctly, you can only kill this process. With what it can be connected and what else it is possible to look at the given problem?
Below are the last entries from the scheduler log before the problem occurred
2022-07-12 05:30:20.986 com.vertica.solutions.kafka.scheduler.StreamCoordinator::Main [INFO] Starting frame # 2022-07-12 05:30:20.986
2022-07-12 05:30:48.837 com.vertica.solutions.kafka.scheduler.LaneWorker::Lane Worker 1 [INFO] Lane Worker 1 waiting for batch...
2022-07-12 05:30:48.837 com.vertica.solutions.kafka.scheduler.StreamCoordinator::Main [INFO] Sleeping for 2149 milliseconds until 2022-07-12 05:30:50.986. Started frame # 2022-07-12 05:30:20.986.
2022-07-12 05:30:51.018 com.vertica.solutions.kafka.scheduler.StreamCoordinator::Main [INFO] Starting frame # 2022-07-12 05:30:51.018
2022-07-12 05:31:21.431 com.vertica.solutions.kafka.scheduler.LaneWorker::Lane Worker 1 [INFO] Lane Worker 1 waiting for batch...
2022-07-12 05:31:21.456 com.vertica.solutions.kafka.scheduler.StreamCoordinator::Main [INFO] Starting frame # 2022-07-12 05:31:21.456
2022-07-12 05:31:30.111 com.vertica.solutions.kafka.scheduler.LaneWorker::Lane Worker 1 [INFO] Lane Worker 1 waiting for batch...
2022-07-12 05:31:30.111 com.vertica.solutions.kafka.scheduler.StreamCoordinator::Main [INFO] Sleeping for 21345 milliseconds until 2022-07-12 05:31:51.456. Started frame # 2022-07-12 05:31:21.456.
2022-07-12 05:31:51.480 com.vertica.solutions.kafka.scheduler.StreamCoordinator::Main [INFO] Starting frame # 2022-07-12 05:31:51.48
2022-07-12 05:32:13.280 com.vertica.solutions.kafka.scheduler.LaneWorker::Lane Worker 1 [INFO] Lane Worker 1 waiting for batch...
2022-07-12 05:32:13.281 com.vertica.solutions.kafka.scheduler.StreamCoordinator::Main [INFO] Sleeping for 8200 milliseconds until 2022-07-12 05:32:21.48. Started frame # 2022-07-12 05:31:51.48.
2022-07-12 05:32:21.505 com.vertica.solutions.kafka.scheduler.StreamCoordinator::Main [INFO] Starting frame # 2022-07-12 05:32:21.505
2022-07-12 05:35:19.932 com.vertica.solutions.kafka.scheduler.config.ConfigurationRefresher::Main_cfg_refresh [INFO] Refreshing Scheduler (refresh interval reached).
2022-07-12 05:35:19.932 com.vertica.solutions.kafka.scheduler.config.ConfigurationRefresher::Main_cfg_refresh [INFO] refresh trial 0

Play: Restart on code change takes long to shutdown and starting the Hikary Pool

Waiting for the server to restart when working with Play cost us a lot of time.
One thing I see in the log is that shutting down and starting the HikaryPool takes a lot of time (> 40 seconds).
Here is the log:
2019-10-31 09:11:47,327 [info] application - Shutting down connection pool.
2019-10-31 09:11:47,328 [info] c.z.h.HikariDataSource - HikariPool-58 - Shutdown initiated...
2019-10-31 09:11:53,629 [info] c.z.h.HikariDataSource - HikariPool-58 - Shutdown completed.
2019-10-31 09:11:53,629 [info] application - Shutting down connection pool.
2019-10-31 09:11:53,629 [info] c.z.h.HikariDataSource - HikariPool-59 - Shutdown initiated...
2019-10-31 09:11:53,636 [info] c.z.h.HikariDataSource - HikariPool-59 - Shutdown completed.
2019-10-31 09:11:53,636 [info] application - Shutting down connection pool.
2019-10-31 09:11:53,636 [info] c.z.h.HikariDataSource - HikariPool-60 - Shutdown initiated...
2019-10-31 09:11:53,640 [info] c.z.h.HikariDataSource - HikariPool-60 - Shutdown completed.
....
2019-10-31 09:12:26,454 [info] p.a.d.DefaultDBApi - Database [amseewen] initialized at jdbc:postgresql://localhost:5432/bpf?currentSchema=amseewen
2019-10-31 09:12:26,454 [info] application - Creating Pool for datasource 'amseewen'
2019-10-31 09:12:26,454 [info] c.z.h.HikariDataSource - HikariPool-68 - Starting...
2019-10-31 09:12:26,455 [info] c.z.h.HikariDataSource - HikariPool-68 - Start completed.
2019-10-31 09:12:26,455 [info] p.a.d.DefaultDBApi - Database [companyOds] initialized at jdbc:sqlserver://localhost:1433;databaseName=companyOds
2019-10-31 09:12:26,455 [info] application - Creating Pool for datasource 'companyOds'
2019-10-31 09:12:26,455 [info] c.z.h.HikariDataSource - HikariPool-69 - Starting...
2019-10-31 09:12:26,456 [info] c.z.h.HikariDataSource - HikariPool-69 - Start completed.
2019-10-31 09:12:26,457 [info] p.a.d.DefaultDBApi - Database [company] initialized at jdbc:oracle:thin:#castor.olymp:1521:citrin
2019-10-31 09:12:26,457 [info] application - Creating Pool for datasource 'company'
2019-10-31 09:12:26,457 [info] c.z.h.HikariDataSource - HikariPool-70 - Starting...
2019-10-31 09:12:26,458 [info] c.z.h.HikariDataSource - HikariPool-70 - Start completed.
2019-10-31 09:12:26,458 [info] p.a.d.DefaultDBApi - Database [amseewen] initialized at jdbc:postgresql://localhost:5432/bpf?currentSchema=amseewen
2019-10-31 09:12:26,458 [info] application - Creating Pool for datasource 'amseewen'
2019-10-31 09:12:26,458 [info] c.z.h.HikariDataSource - HikariPool-71 - Starting...
2019-10-31 09:12:26,459 [info] c.z.h.HikariDataSource - HikariPool-71 - Start completed.
2019-10-31 09:12:26,459 [info] p.a.d.DefaultDBApi - Database [companyOds] initialized at jdbc:sqlserver://localhost:1433;databaseName=companyOds
2019-10-31 09:12:26,459 [info] application - Creating Pool for datasource 'companyOds'
2019-10-31 09:12:26,459 [info] c.z.h.HikariDataSource - HikariPool-72 - Starting...
2019-10-31 09:12:26,459 [info] c.z.h.HikariDataSource - HikariPool-72 - Start completed.
Is there a way to shorten this time?
Updates
I use The Play integration of Intellij. The build-tool is sbt.
Here is the configuration:
sbt 1.2.8
Thread Pools
We use the default thread pool for the application. For the Database access we use:
database.dispatcher {
executor = "thread-pool-executor"
throughput = 1
thread-pool-executor {
fixed-pool-size = 55 # db conn pool (50) + number of cores (4) + housekeeping (1)
}
}
Ok with the help of billoneil on the Hikari Github Page and suggestions of #Issilva, I could figure out the problem:
The problem are now datasources where the database is not reachable (during development). So we configured it, that the application also
starts when the database is not reachable (initializationFailTimeout = -1).
So there are 2 problems when shutting down:
The pools are shutdown sequentially.
A pool that has no connection takes 10 seconds to shutdown.
The suggested solution is not to initialise the datasources that can not be reached. Except a strange exception the shutdown time problem is solved (down to milliseconds).

Kafka vertica consumer and rejection table

I see very strange behavior using vertica kafka consumer:
2016-07-27 04:22:17.307 com.vertica.solutions.kafka.scheduler.StreamCoordinator::Main [INFO] Starting frame # 2016-07-27 04:22:17.307
2016-07-27 04:22:17.330 com.vertica.solutions.kafka.scheduler.FrameScheduler::Main [INFO] Starting compute batches for new Frame.
2016-07-27 04:22:17.431 com.vertica.solutions.kafka.scheduler.FrameScheduler::Main [INFO] Completed computing batch set for current Frame.
2016-07-27 04:22:17.469 com.vertica.solutions.kafka.scheduler.LaneWorker::Lane Worker 2 ("openx"."requests"-CREATE#2016-07-27 04:22:17.431) [ERROR] Rolling back MB: [Vertica][VJDBC](4213) ROLLBACK: Object "requests_rej" already exists
java.sql.SQLSyntaxErrorException: [Vertica][VJDBC](4213) ROLLBACK: Object "requests_rej" already exists
at com.vertica.util.ServerErrorData.buildException(Unknown Source)
at com.vertica.dataengine.VResultSet.fetchChunk(Unknown Source)
at com.vertica.dataengine.VResultSet.initialize(Unknown Source)
at com.vertica.dataengine.VQueryExecutor.readExecuteResponse(Unknown Source)
at com.vertica.dataengine.VQueryExecutor.handleExecuteResponse(Unknown Source)
at com.vertica.dataengine.VQueryExecutor.execute(Unknown Source)
at com.vertica.jdbc.common.SPreparedStatement.executeWithParams(Unknown Source)
at com.vertica.jdbc.common.SPreparedStatement.executeUpdate(Unknown Source)
at com.vertica.solutions.kafka.scheduler.MicroBatch.execute(MicroBatch.java:193)
at com.vertica.solutions.kafka.scheduler.LaneWorker.run(LaneWorker.java:69)
at java.lang.Thread.run(Thread.java:745)
Caused by: com.vertica.support.exceptions.SyntaxErrorException: [Vertica][VJDBC](4213) ROLLBACK: Object "requests_rej" already exists
... 11 more
2016-07-27 04:22:17.469 com.vertica.solutions.kafka.scheduler.LaneWorker::Lane Worker 2 [INFO] Lane Worker 2 waiting for batch...
2016-07-27 04:22:17.469 com.vertica.solutions.kafka.scheduler.StreamCoordinator::Main [INFO] Sleeping for 9838 milliseconds until 2016-07-27 04:22:27.307. Started frame # 2016-07-27 04:22:17.307.
2016-07-27 04:22:27.308 com.vertica.solutions.kafka.scheduler.StreamCoordinator::Main [INFO] Starting frame # 2016-07-27 04:22:27.307
2016-07-27 04:22:27.331 com.vertica.solutions.kafka.scheduler.FrameScheduler::Main [INFO] Starting compute batches for new Frame.
2016-07-27 04:22:27.427 com.vertica.solutions.kafka.scheduler.FrameScheduler::Main [INFO] Completed computing batch set for current Frame.
I do as documentation says, but on write into vertica see this error! Why I see it? How can I fix it?
The error clearly mentions that
Object "requests_rej" already exists
Try dropping the object and running your job.

dotcloud supervisord twistd exiting early

I'm trying to set up a twistd daemon on dotcloud:
My supervisord.conf file:
[program:apnsd]
command=/home/dotcloud/env/bin/twistd --logfile /var/log/supervisor/apnsd.log apnsd -c gp_config.py
directory=/home/dotcloud/current/apnsd
However, it looks like the command 'exits early', which then prompts Supervisor to try and restart, which then fails because the twistd dameon is running in the background.
From the supervisord log:
more supervisord.log
2012-05-19 03:07:52,723 CRIT Set uid to user 1000
2012-05-19 03:07:52,723 WARN Included extra file "/etc/supervisor/conf.d/uwsgi.c
onf" during parsing
2012-05-19 03:07:52,723 WARN Included extra file "/home/dotcloud/current/supervi
sord.conf" during parsing
2012-05-19 03:07:52,922 INFO RPC interface 'supervisor' initialized
2012-05-19 03:07:52,922 WARN cElementTree not installed, using slower XML parser
for XML-RPC
2012-05-19 03:07:52,923 CRIT Server 'unix_http_server' running without any HTTP
authentication checking
2012-05-19 03:07:52,932 INFO daemonizing the supervisord process
2012-05-19 03:07:52,934 INFO supervisord started with pid 144
2012-05-19 03:07:53,941 INFO spawned: 'apnsd' with pid 147
2012-05-19 03:07:53,949 INFO spawned: 'uwsgi' with pid 149
2012-05-19 03:07:54,706 INFO exited: apnsd (exit status 0; not expected)
2012-05-19 03:07:55,712 INFO spawned: 'apnsd' with pid 175
2012-05-19 03:07:55,712 INFO success: uwsgi entered RUNNING state, process has s
tayed up for > than 1 seconds (startsecs)
2012-05-19 03:07:56,261 INFO exited: apnsd (exit status 1; not expected)
2012-05-19 03:07:58,267 INFO spawned: 'apnsd' with pid 176
2012-05-19 03:07:58,783 INFO exited: apnsd (exit status 1; not expected)
2012-05-19 03:08:01,790 INFO spawned: 'apnsd' with pid 177
2012-05-19 03:08:02,840 INFO success: apnsd entered RUNNING state, process has s
tayed up for > than 1 seconds (startsecs)
From the apnsd log:
dotcloud#hack-default-www-0:/var/log/supervisor$ more apnsd-stderr---supervisor
-m7GnKV.log
INFO:root:Reactor Type: <twisted.internet.pollreactor.PollReactor object at 0x10
a09d0>
DEBUG:root:Creating listener: apnsd.listeners.line.LineProtocolFactory
INFO:root:Listening on Line Protocol on :1055
DEBUG:root:Listener Created: <apnsd.listeners.line.LineProtocolFactory instance
at 0x12fc8c0>
DEBUG:root:Creating App Factory: apnsd.daemon.APNSFactory
INFO:root:Connecting to APNS Server, App: apns_dev:AAA.com.company.www
INFO:root:apns_dev:AAA.com.company.www -> Started connecting to APNS con
nector...
INFO:root:Registering Application: apns_dev:GoParcel...
DEBUG:root:Creating App Factory: apnsd.daemon.APNSFactory
INFO:root:Connecting to APNS Server, App: apns_dev:T365ED94A9.com.appitems.parce
ls
INFO:root:apns_dev:T365ED94A9.com.appitems.parcels -> Started connecting to APNS
connector...
INFO:root:Registering Application: apns_dev:GoParcelVictor...
Another twistd server is running, PID 172
This could either be a previously started instance of your application or a
different application entirely. To start a new one, either run it in some other
directory, or use the --pidfile and --logfile parameters to avoid clashes.
Another twistd server is running, PID 172
--More--(42%)
Status of worker is failed:
./dotcloud run hack.worker supervisorctl status
USER PATH IS: C:\Users\Taras/.dotcloud\dotcloud.conf
# supervisorctl status
apnsd FATAL Exited too quickly (process log may
have details)
But the twistd process is there (ps -ef):
dotcloud 171 1 0 03:13 ? 00:00:00 /home/dotcloud/env/bin/python /home/dotcloud/env/bin/twistd --logfile /var/log/supervisor/apnsd.log apnsd -c gp_config.py
I am having a similar problem when trying to start the process through a wrapper script (and using exec so that a child process isn't created). What am I doing wrong?
Supervisor expects the controlled process to remain in the foreground, but twistd forks to the background by default. Supervisor therefore thinks that it has exited, and tries to start it again.
You should start twistd with the --nodaemon option: twistd will remain in the foreground, and Supervisor will be happy!