Thread

  1. postmaster.pid

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-12-03T06:28:44Z

    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
    
    
  2. Re: [HACKERS] postmaster.pid

    Bruce Momjian <pgman@candle.pha.pa.us> — 1999-12-03T07:30:40Z

    > 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, Pennsylvania 19026
    
    
  3. Re: [HACKERS] postmaster.pid

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-12-03T07:56:14Z

    > > 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
    
    
    
  4. Re: [HACKERS] postmaster.pid

    Bruce Momjian <pgman@candle.pha.pa.us> — 1999-12-03T08:06:56Z

    > > > 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, Pennsylvania 19026
    
    
  5. Re: [HACKERS] postmaster.pid

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-12-03T08:17:01Z

    > > 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
    
    
    
  6. Re: [HACKERS] postmaster.pid

    Bruce Momjian <pgman@candle.pha.pa.us> — 1999-12-03T08:38:02Z

    > > > 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, Pennsylvania 19026
    
    
  7. Re: [HACKERS] postmaster.pid

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-12-03T08:43:51Z

    > > 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
    
    
  8. Re: [HACKERS] postmaster.pid

    Ed Loehr <eloehr@austin.rr.com> — 1999-12-03T16:31:36Z

    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
    
    
    
    
  9. Re: [HACKERS] postmaster.pid

    Lamar Owen <lamar.owen@wgcr.org> — 1999-12-03T16:51:59Z

    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
    
    
  10. Re: [HACKERS] postmaster.pid

    Evan Simpson <evan@4-am.com> — 1999-12-03T17:45:55Z

    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
    
    
    
  11. Re: [HACKERS] postmaster.pid

    Tim Holloway <mtsinc@southeast.net> — 1999-12-04T01:47:00Z

    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
    > 
    > ************
    
    
  12. Re: [HACKERS] postmaster.pid

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-12-04T02:37:27Z

    > 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
    
    
  13. Re: [HACKERS] postmaster.pid

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-12-04T02:41:31Z

    > 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
    
    
    
  14. Re: [HACKERS] postmaster.pid

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-12-04T03:02:34Z

    >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
    
    
  15. Re: [HACKERS] postmaster.pid

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-12-04T03:02:44Z

    > > 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