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!