Thread: removing the exec() from doexec()
I'm planning on removing the exec from DoExec() and instead just dispatch to the appropriate function. I don't plan on any changes to the usage of "arguments" to this new process, basically I'll just store them somewhere and then the forked backend can process them. Is there anything I should keep in mind? I'd like this to eventually be integrated into the source tree -- any particular reason why we use exec() when we're just re-invoking the same binary? p.s. this is so my ssl patch doesn't have to negotiate twice -- very expensive
> > > I'm planning on removing the exec from DoExec() and instead just > dispatch to the appropriate function. > > I don't plan on any changes to the usage of "arguments" to this new > process, basically I'll just store them somewhere and then the forked > backend can process them. > > Is there anything I should keep in mind? I'd like this to eventually > be integrated into the source tree -- any particular reason why we use > exec() when we're just re-invoking the same binary? > > p.s. this is so my ssl patch doesn't have to negotiate twice -- very expensive No reason for the exec(). I believe the only advantage is that it gives us a separate process name in the 'ps' listing. I have looked into simulating this. This exec() takes 15% of our startup time. I have wanted it removed for many releases now. The only problem is to rip out the code that re-attached to shared memory and stuff like that, because you will no longer loose the shared memory in the exec(). The IPC code is complicated, so good luck. I or others can help if you get stuck. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
On Wed, 29 Apr 1998, Bruce Momjian wrote:
> No reason for the exec(). I believe the only advantage is that it gives
> us a separate process name in the 'ps' listing. I have looked into
> simulating this.
Under FreeBSD, there is:
setproctitle(3) - set the process title for ps 1
This isn't available under Solaris though, last I checked...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
sure enough.. well, try this on your OS and you can find out if perl
knows how to change it. it doesn't work under solaris. the args to
ps might be different for your system.
perl -e '$0 = "it_works!";system "ps -p $$"'
However, the args to the processes are so different that it seems easy
to tell the difference.. if you're a human. computers might have
more trouble. I've been known to use "killall postgres" (yes, I know,
I'm bad!!)
I only do it so that I can restart the postmaster. Our webserver is
pretty much continually connected, and when it deadlocks, all the
clients queue up. It would be nice to have a set of commands to show
you all connections, the machine/remote port they're from (for
identd), the username/dbname they're connected as, when they
connected, idle time, etc. like "finger" for postgres.
I'm willing to work on it, if someone can point me in the right
direction. (First things first though)
On Wed, 29 April 1998, at 23:20:52, The Hermit Hacker wrote:
>
> Under FreeBSD, there is:
>
> setproctitle(3) - set the process title for ps 1
>
> This isn't available under Solaris though, last I checked...
>
> Marc G. Fournier
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > On Wed, 29 Apr 1998, Bruce Momjian wrote: > > > No reason for the exec(). I believe the only advantage is that it gives > > us a separate process name in the 'ps' listing. I have looked into > > simulating this. > > Under FreeBSD, there is: > > setproctitle(3) - set the process title for ps 1 > > This isn't available under Solaris though, last I checked... Not even BSDI, which is BSD 4.4 like FreeBSD. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> > > sure enough.. well, try this on your OS and you can find out if perl > knows how to change it. it doesn't work under solaris. the args to > ps might be different for your system. > > perl -e '$0 = "it_works!";system "ps -p $$"' > > However, the args to the processes are so different that it seems easy > to tell the difference.. if you're a human. computers might have > more trouble. I've been known to use "killall postgres" (yes, I know, > I'm bad!!) The args don't change on a fork() either. The only way is to look at the parent of all the postgres children. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> > On Wed, 29 Apr 1998, Bruce Momjian wrote: > > > > > No reason for the exec(). I believe the only advantage is that it gives > > > us a separate process name in the 'ps' listing. I have looked into > > > simulating this. > > > > Under FreeBSD, there is: > > > > setproctitle(3) - set the process title for ps 1 > > > > This isn't available under Solaris though, last I checked... > > Not even BSDI, which is BSD 4.4 like FreeBSD. ubik:~$ uname -a Linux ubik 2.0.32 #1 Wed Nov 19 00:46:45 EST 1997 i586 unknown ubik:~$ perl -e '$0 = "it_works!";system "ps p $$"' PID TTY STAT TIME COMMAND 7629 p8 S 0:00 it_works! -dg
> > > > On Wed, 29 Apr 1998, Bruce Momjian wrote: > > > > > > > No reason for the exec(). I believe the only advantage is that it gives > > > > us a separate process name in the 'ps' listing. I have looked into > > > > simulating this. > > > > > > Under FreeBSD, there is: > > > > > > setproctitle(3) - set the process title for ps 1 > > > > > > This isn't available under Solaris though, last I checked... > > > > Not even BSDI, which is BSD 4.4 like FreeBSD. > > ubik:~$ uname -a > Linux ubik 2.0.32 #1 Wed Nov 19 00:46:45 EST 1997 i586 unknown > ubik:~$ perl -e '$0 = "it_works!";system "ps p $$"' > PID TTY STAT TIME COMMAND > 7629 p8 S 0:00 it_works! Let me clarify. BSDI does not have setproctitle, but the perl test does works, sort of: $ perl -e '$0 = "it_works!";system "ps -p $$"' PID TT STAT TIME COMMAND 13095 pc S+ 0:00.02 it_works! rks! ! (perl) -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
The Hermit Hacker <scrappy@hub.org> writes:
> On Wed, 29 Apr 1998, Bruce Momjian wrote:
>> No reason for the exec(). I believe the only advantage is that it gives
>> us a separate process name in the 'ps' listing. I have looked into
>> simulating this.
> Under FreeBSD, there is:
> setproctitle(3) - set the process title for ps 1
> This isn't available under Solaris though, last I checked...
Setting the process title from C is messy, but there is a readily
available reference. The Berkeley sendmail distribution includes code
to emulate setproctitle on practically every platform. See conf.h and
conf.c in any recent sendmail release. Warning: it's grotty enough to
make a strong man weep. Don't read near mealtime ;-)
regards, tom lane
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> This exec() takes 15% of our startup time. I have wanted it removed for
> many releases now.
Don't forget that you will have to use a real fork() rather than
vfork(). Some of the apparent savings will not materialize.
I agree, though, that using exec() to reinvoke the same binary is
pretty silly, especially when you don't want exec's normal side-effects
of detaching shared mem etc. And being able to rip out the dependency
on whether vfork() exists would be nice.
regards, tom lane
> Setting the process title from C is messy, but there is a readily > available reference. The Berkeley sendmail distribution includes code > to emulate setproctitle on practically every platform. See conf.h and > conf.c in any recent sendmail release. Warning: it's grotty enough to > make a strong man weep. Don't read near mealtime ;-) Yep, I have seen it. Good advice. What does grotty mean? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> What does grotty mean?
Hmm, I thought for sure that would be in the Hackers' Dictionary,
but not so. Anyway, it means ugly, messy, contorted, bletcherous,
random.
After you read sendmail's setproctitle code, you'll understand ;-)
regards, tom lane