Thread: Service reboot leaves postmaster.pid
Hello,
I'm running the postmaster as a service using cygrunsrv and this
seems to go fine apart from when I reboot it doesn't seem to remove the
postmaster.pid file, meaning it fails to start automatically after reboot.
Stoping and starting the service manually work fine. Anyone else had this
problem or any pointers where to look (don't know much about NT services).
Thanks,
- Stuart
> -----Original Message----- > From: Henshall, Stuart - WCP > [mailto:SHenshall@westcountrypublications.co.uk] > Sent: 14 June 2001 13:16 > To: 'pgsql-cygwin@postgresql.org' > Subject: [CYGWIN] Service reboot leaves postmaster.pid > > > Hello, > I'm running the postmaster as a service using cygrunsrv > and this seems to go fine apart from when I reboot it doesn't > seem to remove the postmaster.pid file, meaning it fails to > start automatically after reboot. Stoping and starting the > service manually work fine. Anyone else had this problem or > any pointers where to look (don't know much about NT > services). Thanks, Yes, I too have this problem, though I've been too preoccupied with the next release of pgAdmin to do anything about it! Regards, Dave.
I've seen this same problem when using a patched version of postmaster that directly incorporates the service-management functions also provided by cygrunsrv. I eventually got around the problem by changing the postmaster and postgres code to ignore the SIGHUP signal. SIGHUP normally causes postmaster to reread its configuration file. Unfortunately, cygwin code linked into postmaster catches a window-shutdown event during NT shutdown and sends a SIGHUP signal to its own process, causing postmaster to start up its process of rereading the config file. Something about this coincidence causes postmaster to end up in the state where postmaster.pid is still around after restart. I suspect that the reconfiguration process hangs or is aborted during shutdown. I'm planning to submit a patch to cygrunsrv that will give it an optional feature to notice the event of NT shutdown and send a signal to the managed process, much as is done for a manual stop with the '--termsig' option. This will allow us to do the equivalent of 'pg_ctl -m fast stop' or 'pg_ctl -m immediate stop' at that time. But my experiences with a prototype suggest that it's still necessary to ignore SIGHUP in postmaster and postgres in that case because SIGHUP can otherwise still interfere with shutdown. On Thu, Jun 14, 2001 at 01:16:00PM +0100, Henshall, Stuart - WCP wrote: > I'm running the postmaster as a service using cygrunsrv and this > seems to go fine apart from when I reboot it doesn't seem to remove the > postmaster.pid file, meaning it fails to start automatically after reboot. -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
Thanks for the info, do you have a patch for ignoring SIGHUP? If not I guess it'll be time to delve into the source :). - Stuart > -----Original Message----- > From: Fred Yankowski [SMTP:fred@ontosys.com] > Sent: Thursday, June 14, 2001 4:28 PM > To: Henshall, Stuart - WCP > Cc: 'pgsql-cygwin@postgresql.org' > Subject: Re: [CYGWIN] Service reboot leaves postmaster.pid > > I've seen this same problem when using a patched version of postmaster > that directly incorporates the service-management functions also > provided by cygrunsrv. I eventually got around the problem by > changing the postmaster and postgres code to ignore the SIGHUP signal. > > SIGHUP normally causes postmaster to reread its configuration file. > Unfortunately, cygwin code linked into postmaster catches a > window-shutdown event during NT shutdown and sends a SIGHUP signal to > its own process, causing postmaster to start up its process of > rereading the config file. Something about this coincidence causes > postmaster to end up in the state where postmaster.pid is still > around after restart. I suspect that the reconfiguration process > hangs or is aborted during shutdown. > > I'm planning to submit a patch to cygrunsrv that will give it an > optional feature to notice the event of NT shutdown and send a signal > to the managed process, much as is done for a manual stop with the > '--termsig' option. This will allow us to do the equivalent of > 'pg_ctl -m fast stop' or 'pg_ctl -m immediate stop' at that time. But > my experiences with a prototype suggest that it's still necessary to > ignore SIGHUP in postmaster and postgres in that case because SIGHUP > can otherwise still interfere with shutdown. > > On Thu, Jun 14, 2001 at 01:16:00PM +0100, Henshall, Stuart - WCP wrote: > > I'm running the postmaster as a service using cygrunsrv and this > > seems to go fine apart from when I reboot it doesn't seem to remove the > > postmaster.pid file, meaning it fails to start automatically after > reboot. > > -- > Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 > Principal Consultant www.OntoSys.com fax: +1.630.879.1370 > OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl
Hello, > I'm running the postmaster as a service using cygrunsrv and this > seems to go fine apart from when I reboot it doesn't seem to remove the > postmaster.pid file, meaning it fails to start automatically after reboot. > Stoping and starting the service manually work fine. Anyone else had this > problem or any pointers where to look (don't know much about NT services). I have the same problem using Windows 2000, but I have the impression that no signal will be sent to the postmaster on reboot or shutdown. When I am stopping the service manually with 'net stop ...', a shutdown message will be written. Does Windows 2000 stops all services explicitely or will the processes be stopped only? -- =============================================================== Rolf Rolfs Hölderlinweg 8/2 mailto:rolf@familie-rolfs.de 71729 Erdmannhausen Tel.: +49 7144 331415 ===============================================================
I just tried re-building postgres for cygwin, using patches only to ignore SIGHUP and not my other service-management cruft. Unfortunately, testing shows that this doesn't suffice to get postgres to start up cleanly after NT restart when run under cygrunsrv. The postmaster.pid file is still left around. My plan to create a patch for cygrunsrv that allows it to send a signal to the managed service process when it (cygrunsrv) is notified that NT is shutting down. Note that someone else on the Cygwin email list reports occasional problems where cygrunsrv completely fails to start after NT restart. In their case they're using it for sshd, not postgres, but even so I'm somewhat concerned that cygrunsrv may have some timing-related initialization problem. On Fri, Jun 15, 2001 at 08:53:33AM +0100, Henshall, Stuart - WCP wrote: > Thanks for the info, do you have a patch for ignoring SIGHUP? If not I guess > it'll be time to delve into the source :). -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
> Note that someone else on the Cygwin email list reports occasional
> problems where cygrunsrv completely fails to start after NT restart.
> In their case they're using it for sshd, not postgres, but even so I'm
> somewhat concerned that cygrunsrv may have some timing-related
> initialization problem.
with your patch applied to 0.93-1 postmaster gets a signal and shuts down
properly. but after reboot it fails to start anyway. SCM writes error event
saying "Timeout (30000 milliseconds) waiting for the Cygwin PostgreSQL
Server service to connect". i've tried to track down a problem, but for me
it looks like that cygrunsrv isn't executing at all! (maybe i'm wrong, but
log = fopen("/svclog.txt", "w"); fprintf(log, "main %d\n", logcnt++);
fflush(log);
in the beginning of main() does nothing after reboot. when service is
started manually, it works fine) nevertheless i can see cygrunsrv.exe
process in task manager. but it gets killed before i can attach a debugger
to see what's it doing...
/Dmitry
P.S. 4 hunks of your patch get rejected against 0.93-1 - it doesn't have
'dir' args in reg manipulation functions.
Dmitri, On Sat, Jun 16, 2001 at 08:55:15PM +0400, Dmitry Yurtaev wrote: > with your patch applied to 0.93-1 postmaster gets a signal and shuts down > properly. but after reboot it fails to start anyway. SCM writes error event > saying "Timeout (30000 milliseconds) waiting for the Cygwin PostgreSQL > Server service to connect". i've tried to track down a problem, but for me > it looks like that cygrunsrv isn't executing at all! That sounds like the same symptom that the other guy saw with sshd. I've never encountered that problem and don't know how to recreate it to do any testing. As you mention, it's a b**** to test anyway because it happens during NT startup. It seems that the Cygwin DLL does some initialization when it is first loaded (to link with the first application that depends on it). One guess as to what's happening is that cygrunsrv is the first such Cygwin application and something occurs during DLL init that hangs when it happens early in the NT startup process. Putting some kind of debug traces into dll_init.cc might be a place to start, but I don't know how to recreate the problem to where this would be useful. > P.S. 4 hunks of your patch get rejected against 0.93-1 - it doesn't have > 'dir' args in reg manipulation functions. My patches are relative to the latest (as of yesterday) CVS version of the cygrunsrv source. -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
> > but after reboot it fails to start anyway. SCM writes error event > > saying "Timeout (30000 milliseconds) waiting for the Cygwin PostgreSQL > > Server service to connect". > That sounds like the same symptom that the other guy saw with sshd. > I've never encountered that problem and don't know how to recreate it > to do any testing. it appears that you were right about DLL initialization - just got the latest snapshot of cygwin1.dll (20010615) and the problem gone away. trouble was with cygwin-1.3.2-1. /Dmitry