Sven Willenberger sven
Wed Jul 27 21:13:04 PDT 2005
On Wed, 2005-07-27 at 11:47 -0400, Sven Willenberger wrote:
> On Tue, 2005-07-26 at 16:29 -0400, Sven Willenberger wrote:
> > On Tue, 2005-07-26 at 16:21 -0400, Vivek Khera wrote:
> > > On Jul 26, 2005, at 2:56 PM, Sven Willenberger wrote:
> > > 
> > > > I would much prefer to use the supplied startup script so that I  
> > > > can use
> > > > syslog logging (and newsyslog file rotation using the slon.pid). Any
> > > > ideas on how to get this script to background slony and to suppress  
> > > > all
> > > > output to terminal?
> > > >
> > > 
> > > I personally don't use it, so haven't spent much time debugging it...
> > > 
> > > I use the slon-mkservice script (which I posted a few hours ago here,  
> > > tooo) fromth eport and run it via daemontools.
> > > 
> > > Vivek Khera, Ph.D.
> > > +1-301-869-4449 x806
> > 
> > I will take a look at using deamontools then. I had seen the thread to
> > which you refer and that  prompted my question (but I didn't want to
> > hijack the thread). 
> > 
> > Thanks
> 
> 
> The setup script worked fine and the service is running. I do have a
> concern now though. It would appear from the logfiles that slon is
> getting restarted every 12 minutes on the origin. Subsequently, the
> replicant does the same an spits out warnings:
> 
> Jul 27 11:40:27 dbhost slon[48276]: [43-22] CONFIG storeListen:
> li_origin=1 li_receiver=3 li_provider=1
> Jul 27 11:40:27 dbhost slon[48276]: [43-23] CONFIG storeSet: set_id=1
> set_origin=1 set_comment='customer tables'
> Jul 27 11:40:27 dbhost slon[48276]: [43-24] WARN   remoteWorker_wakeup:
> node 1 - no worker thread
> Jul 27 11:40:27 dbhost slon[48276]: [43-25] CONFIG storeSet: set_id=4
> set_origin=1 set_comment='Temp set to integrate'
> Jul 27 11:40:27 dbhost slon[48276]: [43-26] WARN   remoteWorker_wakeup:
> node 1 - no worker thread
> 
> 
> Is this normal? or is svscan somehow under the impression that slon
> stopped running?
> 
> Sven
> 

Now the next thing I am noticing is that each time this happens, the
parent pid (of slon) does not change, but another listener is set up? In
the log files, for example I see the following scenario:

Jul 27 15:28:28  slon[46792]: [22-34] DEBUG1 cleanupThread: thread
starts
Jul 27 15:28:28  slon[46792]: [22-35] DEBUG1 remoteListenThread_3:
connected to ...
Jul 27 15:28:28  slon[46792]: [22-36] DEBUG1 cleanupThread:    0.046
seconds for cleanupEvent()
Jul 27 15:28:28  slon[46792]: [22-37] DEBUG1 cleanupThread:    0.025
seconds for delete logs

Jul 27 15:39:52  slon[46792]: [24-34] DEBUG1 cleanupThread: thread
starts
Jul 27 15:39:52  slon[46792]: [24-35] DEBUG1 remoteListenThread_3:
connected to ...
Jul 27 15:39:52  slon[46792]: [24-36] DEBUG1 cleanupThread:    0.046
seconds for cleanupEvent()
Jul 27 15:39:52  slon[46792]: [24-37] DEBUG1 cleanupThread:    0.025
seconds for delete logs
Jul 27 15:39:52  slon[46792]: [24-38] DEBUG1 cleanupThread:    0.039
seconds for cleanupEvent()
Jul 27 15:39:52  slon[46792]: [24-39] DEBUG1 cleanupThread:    0.018
seconds for delete logs

Jul 27 15:51:48  slon[46792]: [25-34] DEBUG1 cleanupThread: thread
starts
Jul 27 15:51:48  slon[46792]: [25-35] DEBUG1 remoteListenThread_3:
connected to ...
Jul 27 15:51:48  slon[46792]: [25-36] DEBUG1 cleanupThread:    0.046
seconds for cleanupEvent()
Jul 27 15:51:48  slon[46792]: [25-37] DEBUG1 cleanupThread:    0.025
seconds for delete logs
Jul 27 15:51:48  slon[46792]: [25-38] DEBUG1 cleanupThread:    0.039
seconds for cleanupEvent()
Jul 27 15:51:48  slon[46792]: [25-39] DEBUG1 cleanupThread:    0.018
seconds for delete logs
Jul 27 15:51:48  slon[46792]: [25-40] DEBUG1 cleanupThread:    0.025
seconds for cleanupEvent()
Jul 27 15:51:48  slon[46792]: [26-41] DEBUG1 cleanupThread:    0.017
seconds for delete logs


and for each "restart" like this (I say restart, although the parent pid
remains the same) the number of "Thread" entries increases ... as if the
supervisor is not aware of the the listener threads (?) -- I am not
entirely familiar with the actual inner workings of slony to know how
this all ties together.

Sven



More information about the Slony1-general mailing list