Thread: postmaster.pid
Hi, I have committed changes to postmaster.c. Now it creates a file called "postmaster.pid" under $PGDATA, which holds postmaster's process id. If the file has already existed, postmaster won't start. So we cannot start more than on postmaster with same $PGDATA any more. I believe it's a good thing. The file will be deleted upon postmaster shutting down. Another file "postmaster.opts" is also created under $PGDATA. It contains the path to postmaster and each option for postmaster per line. Example contents are shown below: /usr/local/pgsql/bin/postmaster -p 5432 -D /usr/local/pgsql/data -B 64 -b /usr/local/pgsql/bin/postgres -N 32 -S Note that even options execpt -S is not explicitly supplied in the case above (postmaster -S), other opts are shown. This file is not only convenient to restart postmaster but also is usefull to determin with what defaults postmaster is running, IMHO. With these changes now we can stop postmaster: kill `cat /usr/local/pgsql/data/postmaster.pid` To restart it with previous options: eval `cat /usr/local/pgsql/data/postmaster.opts` I'm going to write pg_ctl script this week end. BTW, no initdb required, of course. -- Tatsuo Ishii
> Hi, > > I have committed changes to postmaster.c. Now it creates a file called > "postmaster.pid" under $PGDATA, which holds postmaster's process > id. If the file has already existed, postmaster won't start. So we > cannot start more than on postmaster with same $PGDATA any more. I > believe it's a good thing. The file will be deleted upon postmaster > shutting down. I assume you do a kill(0) on the pid if the file exists on startup to check to see if the pid is still valid? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > I have committed changes to postmaster.c. Now it creates a file called > > "postmaster.pid" under $PGDATA, which holds postmaster's process > > id. If the file has already existed, postmaster won't start. So we > > cannot start more than on postmaster with same $PGDATA any more. I > > believe it's a good thing. The file will be deleted upon postmaster > > shutting down. > > I assume you do a kill(0) on the pid if the file exists on startup to > check to see if the pid is still valid? A little bit different. 1) if the port is already in use, postmaster exits (same as before) 2) if it fails to create pid file, call ExitPostmaster(1). ExitPostmaster calls proc_exit() and proc_exit calls exit(). -- Tatsuo Ishii
> > > I have committed changes to postmaster.c. Now it creates a file called > > > "postmaster.pid" under $PGDATA, which holds postmaster's process > > > id. If the file has already existed, postmaster won't start. So we > > > cannot start more than on postmaster with same $PGDATA any more. I > > > believe it's a good thing. The file will be deleted upon postmaster > > > shutting down. > > > > I assume you do a kill(0) on the pid if the file exists on startup to > > check to see if the pid is still valid? > > A little bit different. > > 1) if the port is already in use, postmaster exits (same as before) OK > 2) if it fails to create pid file, call > ExitPostmaster(1). ExitPostmaster calls proc_exit() and proc_exit > calls exit(). So you don't start if the pid file is there, or do you delete it if the port is free? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > 2) if it fails to create pid file, call > > ExitPostmaster(1). ExitPostmaster calls proc_exit() and proc_exit > > calls exit(). > > So you don't start if the pid file is there, Right. >or do you delete it if the > port is free? No. even if the port is free, there might be another postmaster that uses another one. Wait, maybe I can check postmaster.opts to see if another postamster really exists... -- Tatsuo Ishii
> > > 2) if it fails to create pid file, call > > > ExitPostmaster(1). ExitPostmaster calls proc_exit() and proc_exit > > > calls exit(). > > > > So you don't start if the pid file is there, > > Right. > > >or do you delete it if the > > port is free? > > No. even if the port is free, there might be another postmaster that > uses another one. > > Wait, maybe I can check postmaster.opts to see if another postamster > really exists... You can do kill(0) on the pid to see if it is actually a real pid. Rather than playing with the port, just check the pid because the postmaster could be startup up by not on the port yet. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > Wait, maybe I can check postmaster.opts to see if another postamster > > really exists... > > You can do kill(0) on the pid to see if it is actually a real pid. > Rather than playing with the port, just check the pid because the > postmaster could be startup up by not on the port yet. Oh, I see your point now. -- Tatsuo Ishii
Tatsuo Ishii wrote: > Another file "postmaster.opts" is also created under $PGDATA. It > contains the path to postmaster and each option for postmaster per > line. Example contents are shown below: > > /usr/local/pgsql/bin/postmaster > -p 5432 > -D /usr/local/pgsql/data > -B 64 > -b /usr/local/pgsql/bin/postgres > -N 32 > -S > > Note that even options execpt -S is not explicitly supplied in the > case above (postmaster -S), other opts are shown. This file is not > only convenient to restart postmaster but also is usefull to determin > with what defaults postmaster is running, IMHO. It's not quite clear to me: Do command line options override postmaster.opts options? (I would expect them to.) Cheers. Ed
Ed Loehr wrote: > Tatsuo Ishii wrote: > > Another file "postmaster.opts" is also created under $PGDATA. It > > contains the path to postmaster and each option for postmaster per > > line. Example contents are shown below: [snip] > > Note that even options execpt -S is not explicitly supplied in the > > case above (postmaster -S), other opts are shown. This file is not > > only convenient to restart postmaster but also is usefull to determin > > with what defaults postmaster is running, IMHO. > It's not quite clear to me: Do command line options override > postmaster.opts options? (I would expect them to.) >From what I gather from Tatsuo's message, the 'postmaster.opts' file only shows the status of the currently running postmaster -- IOW, it's not a configuration file, but a status indicator. And I like the idea of this status information being available in this way. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Tatsuo Ishii wrote: > I have committed changes to postmaster.c. Now it creates a file called > "postmaster.pid" under $PGDATA, which holds postmaster's process > id. If the file has already existed, postmaster won't start. Do you just test to see if the file exists? If so, I would suggest actually reading the pid and checking to see if the process is still running. That way we don't have to 'rm postmaster.pid' if the postmaster dies abnormally (Netscape for Linux has this problem). Cheers, Evan @ 4-am
I hope you don't mind being superseded. I hope (FINALLY!) to be able to post
the patches for the log subsystem in the next week or three. The log system
has a fairly sophisticated set of options which required a config file of
its own. Rather than have two options file, I absorbed pg_options and made
a general options file: "postgres.conf".
Could you accept this:
/* postgres.conf */ environment {port 5432;pidfile "/usr/local/pgsql/data";/* etc. */ }
debugging { /* pg_options info */ }
logging { /* logging info */ }
For more info, see http://216.199.14.27/
regards,
Tim Holloway
The logger supports reporting the run environment, BTW. I find
that way I don't pick up the wrong config file and only "think" I
know what options are in effect (it also reports where it GOT
the config file).
Tatsuo Ishii wrote:
>
> Hi,
>
> I have committed changes to postmaster.c. Now it creates a file called
> "postmaster.pid" under $PGDATA, which holds postmaster's process
> id. If the file has already existed, postmaster won't start. So we
> cannot start more than on postmaster with same $PGDATA any more. I
> believe it's a good thing. The file will be deleted upon postmaster
> shutting down.
>
> Another file "postmaster.opts" is also created under $PGDATA. It
> contains the path to postmaster and each option for postmaster per
> line. Example contents are shown below:
>
> /usr/local/pgsql/bin/postmaster
> -p 5432
> -D /usr/local/pgsql/data
> -B 64
> -b /usr/local/pgsql/bin/postgres
> -N 32
> -S
>
> Note that even options execpt -S is not explicitly supplied in the
> case above (postmaster -S), other opts are shown. This file is not
> only convenient to restart postmaster but also is usefull to determin
> with what defaults postmaster is running, IMHO.
>
> With these changes now we can stop postmaster:
>
> kill `cat /usr/local/pgsql/data/postmaster.pid`
>
> To restart it with previous options:
>
> eval `cat /usr/local/pgsql/data/postmaster.opts`
>
> I'm going to write pg_ctl script this week end.
>
> BTW, no initdb required, of course.
> --
> Tatsuo Ishii
>
> ************
> I hope you don't mind being superseded. I hope (FINALLY!) to be able to post > the patches for the log subsystem in the next week or three. The log system > has a fairly sophisticated set of options which required a config file of > its own. Rather than have two options file, I absorbed pg_options and made > a general options file: "postgres.conf". I'm not sure about your postgres.conf, but I think pg_options was made for postgres - the backend - not for postmaster. This is the reason why I invented yet another conf file. Anyway, could you post the patches so that we could evaluate them? -- Tatsuo Ishii
>From what I gather from Tatsuo's message, the 'postmaster.opts' file > only shows the status of the currently running postmaster -- IOW, it's > not a configuration file, but a status indicator. Right. Thanks for the cleaner explation! > And I like the idea of this status information being available in this > way. Me too. -- Tatsuo Ishii
> Do you just test to see if the file exists? If so, I would suggest > actually reading the pid and checking to see if the process is still > running. That way we don't have to 'rm postmaster.pid' if the postmaster > dies abnormally (Netscape for Linux has this problem). Thanks for the suggestion. I have already modified postmaster.c so that it could remove postmaster.pid if the file is bogus. Will commit soon. -- Tatsuo Ishii
> > Note that even options execpt -S is not explicitly supplied in the > > case above (postmaster -S), other opts are shown. This file is not > > only convenient to restart postmaster but also is usefull to determin > > with what defaults postmaster is running, IMHO. > > It's not quite clear to me: Do command line options override > postmaster.opts options? (I would expect them to.) No, postmaster.opts is just showing what options have been passed to postmatser. Using it to determine what options should be given next time is the job of pg_ctl which I'm writing now, not postmaster's. Speaking about pg_ctl, probably I will give it the ability to override postmaster.opts options. -- Tatsuo Ishii