Re: [exim-dev] exim 4.50 hp-ux 11.23 (ipf) startup problems

Pàgina inicial
Delete this message
Reply to this message
Autor: V. T. Mueller
Data:  
A: exim-dev
Assumpte: Re: [exim-dev] exim 4.50 hp-ux 11.23 (ipf) startup problems

Hello Michael,

Michael Haardt schrieb:
>>In short: it runs but is not capable of running as a _background_
>>daemon. This might be linked to the changes in the daemon startup
>>code that has been discussed on this list lately.
> Not quite the same, but the closest you may get here. Using +O2 (+O3
> runs out of memory on pcre) I can compile Exim and start it as daemon.
> Trying to start it using tusc -f fails without an error, almost at the
> same point:


That's odd. I have never had any problem swith tusc before. But I
see the same behaviour here with 11.11/4.20, too. (Never had the
need to trace exim before ;)

> So that behaviour does not depend on the architecture or compiler, but
> probably on HP-UX or tusc. Too bad. What exactly happens if you start
> it without tusc attached? Is there anything in the logs why the daemon
> does not work for you?


Thats the point. It runs fine when not being put into background. If
started with "-bd", it will create a pid file and a normal entry in
main.log - nothing in the panic log. It just goes away (exit(0)).

> I do get similar warnings, too. According to iconv(3c), the second
> argument is "const char **inbuf". According to /usr/include/iconv.h,
> it is "char **". If this gets rid of the warnings on iconv and
> socklen_t for you too, we should use it as default:
>
> OS/Makefile-HP-UX:
>
> # HP-UX ANSI C compiler
> #CC=cc
> #CFLAGS=+O2 +Onolimit -D_XOPEN_SOURCE_EXTENDED
> # gcc
> CFLAGS=-O -D_XOPEN_SOURCE_EXTENDED
>
> OS/os.h-HP-UX:
>
> /* Other OS have "const" in here */
> #define ICONV_ARG2_TYPE char **
>
> Btw: My kernel image is called "/stand/vmunix". Could it possibly have been
> /hp-ux" for HP-UX 10? In that case, perhaps we need OS/*-HP-UX{9,10,11}.


The kernel moved to /stand in rel. 10. So that define is garbage,
anyway. There are major changes in the way kernel modules are
organized now in 11.23, but I doubt there lies a reason in that
simply because the current define has been wrong for several years
and noone appears to have noticed it before you did ;)

I was hoping for a small & stupid reason for the problem, now it
looks as there is a real issue. I'll attempt some more os-level
debugging and see what I can come up with. For the code related
points I'll have to ask a colleague who is more familiar with C.

Cheers,
vt