On Fri, 18 Nov 2005, David Lee wrote:
[...]
Still bad. Still getting error return from setenv (-> OS putenv).
But I think I've found the problem area. The heartbeat code does things
directly with the (system provided) "environ" variable. One such example is
in "lib/clplumbing/setproctitle.c:set_proc_title()".
A local test commenting most of the heart of "set_proc_title()" restores
sanity: putenv() works cleanly and successfully. And that means that
heartbeat 2.0.x can actually now run on Solaris-8!
Clearly, the code's dabbling directly with environ can upset "putenv()"
on some OSes. I'll try to tidy this up.
"lib/clplumbing/setproctitle.c": In brief, I propose the attached patch,
to be added later this week, so that "PF_ARGV_TYPE == PF_ARGV_NONE"
disables all the code.
Detail:
1. Hitherto, "init_set_proc_title()" does lots of dabbling with "argv" and
"environ", etc. for any setting of "PF_ARGV_TYPE", even "PF_ARGV_NONE".
This feels wrong: the "...NONE", I think, should strongly imply "no
dabbling, please".
2a. Solaris (Sun Microsystems) doesn't seem to offer any supported
(official) mechanism for changing the string as viewed by the default "ps"
("/usr/bin/ps") command.
2b. Solaris's non-default "/usr/ucb/ps" flavour of "ps" (with the right
set of flags) does seem able to see such changes in other programs, e.g.
from sendmail. But only, it seems, on S9, not on either S8 or S10!
3. sendmail's source is convoluted. But at a glance, it looks somewhat
cleaner that the version we have (ex-ProFTPD, I understand).
4. Tempted to switch to sendmail as our model source code?
(i) Would licensing allow us (heartbeat) to do that?
(ii) Is there any guarantee that Sun's sendmail corresponds to sendmail's
own version? (Sun's version has had differences...)
All-in-all, chasing setproctitle-equivalent functionality seems to be
diminishing returns. The current implementation causes damage on
Solaris-8; we ought to have "PF_ARGV_NONE" working (and doing so with
intuitively "NONE" impact) anyway.
Does heartbeat software actually functionally use the result of
"setproctitle"? My guess it is simply "pretty printing", nothing more,
for human viewing of "ps" output.
Hence my proposed patch.
(Note that to drive this we'll need to modify "configure.in" so that
value "PF_ARGV_NONE" gets set: but that's another story...)
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: Durham University :
: http://www.dur.ac.uk/t.d.lee/ South Road :
: Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
--- lib/clplumbing/setproctitle.c.orig Thu Apr 21 00:42:17 2005
+++ lib/clplumbing/setproctitle.c Tue Nov 22 17:58:44 2005
@@ -75,8 +75,11 @@
#include <clplumbing/setproctitle.h>
+#if PF_ARGV_TYPE != PF_ARGV_NONE
static char **Argv = NULL;
static char *LastArgv = NULL;
+#endif /* PF_ARGV_TYPE != PF_ARGV_NONE */
+
extern char **environ;
#ifdef HAVE___PROGNAME
@@ -87,6 +90,9 @@
int
init_set_proc_title(int argc, char *argv[], char *envp[])
{
+#if PF_ARGV_TYPE == PF_ARGV_NONE
+ return 0;
+#else
int i;
int envpsize;
char **p;
@@ -148,10 +154,12 @@
}
ha_free(environ);
return -1;
+#endif /* PF_ARGV_TYPE == PF_ARGV_NONE */
}
void set_proc_title(const char *fmt,...)
{
+#if PF_ARGV_TYPE != PF_ARGV_NONE
va_list msg;
static char statbuf[BUFSIZ];
@@ -224,4 +232,6 @@
#endif /* PF_ARGV_PSSTRINGS */
#endif /* HAVE_SETPROCTITLE */
+
+#endif /* PF_ARGV_TYPE != PF_ARGV_NONE */
}
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
